我们团队最早被这个问题逼疯是在给一个计算几何库做 Python 接口的时候。算法部分全是 C性能敏感但整个验证和测试流程又都跑在 Python 生态里。一开始图省事用 subprocess 调命令行工具把结果写文件再让 Python 读低效且痛苦。后来认真考察了 pybind11、ctypes、Python C API 这三条主流路线才算把这摊事彻底理顺。这篇文章就把这三条路线放在一起做一次系统对比。我会从底层原理讲起再落到开发效率、运行性能、类型支持这些实际维度最后用同一个案例分别写出三种实现并分享我在长期维护中踩过的坑。适合两类人看一类是给 Python 项目接入 C/C 库另一类是手上有 C 核心代码想对 Python 开接口。看完之后你应该能清楚判断自己该选哪条路。1. 三条技术路线底层逻辑与选型前提1.1 混合编程的本质是把两套运行时拼在一起很多人一开始容易把“给 Python 写 C 扩展”当成一件简单的事无非就是编译一个 .so 或者 .dll 让 Python 加载呗。但真正做起来就会发现难点全在“类型系统”和“生命周期管理”上。Python 侧的一切对象都是 PyObject*整数是变长结构体字符串是 Unicode 序列每个对象都有引用计数垃圾回收由解释器统一调度。C 侧则是静态类型、数值直接放栈上、对象用 RAII 管理、内存靠构造析构。两端对“一个整数”“一个字符串”“一个对象”的理解完全不同。混合编程本质上就是在这两套运行时之间造一座桥要么你手动处理 PyObject* 的转换和引用计数要么你把类型描述交给框架让框架在编译期或运行期帮你生成转换逻辑。这三条路线正好代表了三种不同的造桥思路。Python C API 是“你自己一砖一瓦砌桥”ctypes 是“站在河边喊对面按对方的规矩递东西”pybind11 是“用模板元编程在编译期把桥自动浇筑出来”。理解了这个底层差异后面很多选型判断就顺理成章了。1.2 三种方案的内核手写、声明、自动生成先分别说清楚它们到底是什么。Python C API 是 CPython 官方提供的 C 接口。所有用 C 写 Python 扩展的能力本质上都是在跟 PyObject* 打交道。你要自己写模块初始化函数、自己定义 PyMethodDef 方法表、自己调用 PyArg_ParseTuple 解析参数、自己构造返回对象、自己管理引用计数和 GIL。这套东西能力极强因为它就是解释器本身用的接口但同时它也是最啰嗦、最容易出错的一种方式。ctypes 走的是另一条路。它是 Python 标准库自带的外部函数接口FFI不需要你写 C/C 扩展模块而是由 Python 在运行时加载动态库然后你在 Python 侧声明函数的参数类型和返回类型ctypes 根据声明完成调用。它不关心你背后是 C 还是 C 编译出来的库只关心能否按 C ABI 调用到符号。这是它对现有代码侵入性最小的重要原因也是它处理不了 C 高级特性的根本原因。pybind11 是近年来社区主推的方案。它是一个纯头文件的 C 库基于 C11/14/17 的模板元编程在编译期自动生成绑定代码。你写的是很“描述性”的代码比如 m.def(add, add)编译器会基于类型推断生成一整套 C API 层的胶水代码。它的目标就是既保留接近手写 C API 的性能又把开发效率提升到接近纯 Python 的水平。这三者的关系不是简单的“谁替代谁”而是定位完全不同。你可以把 Python C API 想象成直接操作寄存器和机器码把 ctypes 想象成寄快递时只填一张面单把 pybind11 想象成用一套自动化工装批量生产零件。哪个适合你取决于你要做的是“解释器深度定制”“快速调用现有库”还是“长期维护一个 C 库的 Python 接口”。1.3 每个方案真正的舒适区在哪里用我自己的项目经验来标注一下。Python C API 的舒适区在“你不知道还能怎么办”的场景。比如你想实现一个自定义嵌入式宿主让 C 程序把 Python 当作脚本引擎调用那么你必须深入 C API又比如你想修改 Python 内置类型的行为、写性能分析器或者调试工具也只有 C API 能做到。这类需求很少但一旦遇到就是硬性的。ctypes 的舒适区是“调用别人已经编译好的动态库”。很多第三方 SDK、老式 C 库、操作系统接口只提供 C ABI 的动态库和头文件。用 ctypes 你不需要改动这些库的构建方式直接在 Python 侧写声明就能调用。如果接口不多而且对方没有再开发迭代的需求ctypes 是最快路径。pybind11 的舒适区是“你自己在维护这个 C 库”。因为要写绑定你得在 C 代码里加入 pybind11 头文件并显式声明暴露哪些接口这本身就是一种持续开发。当接口规模超过十几个、涉及类继承和 STL 容器、或者需要长期跟进 C 库的功能迭代时pybind11 的维护成本优势会极其明显。这也是现在大多数开源库比如 OpenCV 的部分模块、各种 3D 几何库优先选择它的原因。2. 核心维度对比性能、效率、类型与工程集成2.1 开发效率与代码量先把账算清楚衡量一种绑定方案好不好用最直观的指标就是“暴露一个函数要写多少行代码”。拿最简单的整数加法来算Python C API 要写 PyMethodDef 数组、PyModuleDef 结构体、函数内部还要解析参数和构造返回值再加上模块初始化入口随便就是三十行往上。ctypes 不用改 C但要在 Python 侧声明 argtypes 和 restype而且格式是 ctypes 自己的类型对象写得多了也烦。pybind11 就是一行 m.def(add, add)。这个差距在只有两三个函数时不算大但接口数量一旦涨到几十上百个C API 的维护成本会变成灾难。我见过一个老项目扩展模块两千多行一半以上是 PyArg_ParseTuple 的参数解析格式串和 Py_BuildValue 的返回构造代码这些代码几乎没有信息量全是重复劳动还特别容易错。pybind11 把这些全部放到了模板层写接口就是写 C 函数本身注册函数只用一行声明可读性完全是两个世界。ctypes 在开发效率上介于两者之间。它省去了 C 侧编译扩展模块的环节启动快、调试直观但 Python 侧的手写声明和 C 头文件是“两套真相”。一旦 C 侧改了参数类型Python 侧没同步运行结果就会诡异。如果接口少这问题不突出接口一多维护这份并行声明的成本就上来了。pybind11 还顺带赠送了一堆日常高频能力参数名绑定Python 侧可以用关键字调用、自动文档字符串、运算符重载导出、lambda 表达式、甚至 py::array 对 Numpy 数组的零拷贝转换。这些能力用 C API 都要手写而且写起来复杂程度远超想象。所以开发效率这一项我的结论很明确如果你在持续开发 C 库pybind11 的优势是数量级上的不是百分比上的。2.2 运行性能与 GIL 策略不能只看“调用快不快”性能是大家最敏感的维度但也最容易被带偏。从底层机制来说Python C API 是解释器原生调用理论上延迟最低pybind11 底层调用的仍然是 C API只是有一层模板封装实际测试中绝大多数场景和手写 C API 几乎持平差距常常在个位数百分比以内ctypes 因为要经过运行时 FFI 层多出参数装箱、类型校验、函数指针解析这些步骤单次调用开销明显更大。我做过一个粗测同一个简单的整数加法函数循环调用一百万次ctypes 的耗时大约是 pybind11 的三到五倍。这个差距在单次调用场景下完全无所谓但如果你在 Python 层写了一个热点循环里面反复调用 C 函数那 ctypes 的开销就会被无限放大。反过来如果调用频率很低或者每次 C 调用本身的耗时远大于 FFI 开销比如内部在做大量计算ctypes 完全够用。GIL 策略是另一个容易被忽略的维度。Python C API 提供 Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS 宏可以手动释放 GIL 让 C 侧长时间计算不阻塞其他 Python 线程。pybind11 封装了 py::gil_scoped_release用 RAII 风格控制代码更安全。ctypes 在调用外部函数时也会释放 GIL调用结束后重新获取所以从“重型计算”这个角度看ctypes 也没问题。但 pybind11 和 C API 的 GIL 控制粒度更细你可以决定哪一段代码持锁、哪一段释放这对精细调优很重要。2.3 类型系统支持的边界C 类型、STL 和自定义类类型系统的支持范围是三种方案分化的核心。Python C API 在类型转换上是“全手动”。任何类型你都可以通过 API 手动构建成 PyObject但代价是每个类型转换都要自己写代码。C 基础类型有一堆现成宏比如 PyLong_FromLong、PyFloat_FromDouble字符串要区分 PyUnicode 和 PyBytes结构体要自己创建 PyStruct 或者包成 PyCapsuleSTL 容器你得把 std::vector 遍历出来转成 PyList。灵活度最高但工作量和出错概率也最高。ctypes 能表达的就是 C 类型整数、浮点、指针、结构体、联合体、函数指针。C 的 std::string、std::vector 它完全不懂。如果你想用 ctypes 调用一个接受 std::string 的函数你得在 C 侧重新写一层 extern C 包装把 std::string 拆成 const char*把 std::vector 拆成指针加长度。这种包装一旦变多ctypes 就失去了“方便”的意义本质上变成了自己维护一层薄薄的 C 接口层还不如直接上 pybind11。pybind11 在类型支持上是“天生的富户”。内置 type caster 对 std::string、std::vector、std::map、std::unordered_map、std::shared_ptr 等都有现成支持自动在 STL 容器和 Python 原生容器之间转换。更关键的是py::class_ 可以完整暴露一个 C 类构造函数、成员函数、成员变量、静态方法、运算符重载、虚函数多态全都能导出。这是 ctypes 做不到的也是 C API 做起来累死人的事。如果你要绑定的对象带有复杂的对象语义pybind11 几乎是唯一现实的选择。2.4 工程集成、依赖与分发表格看差异把工程层面的维度整理成一张表会更清楚。维度Python C APIctypespybind11接口形式编译为 Python 扩展模块运行时加载动态库编译为 Python 扩展模块是否需要改 C 源码需要写胶水层不需要但需 C ABI 接口需要写绑定层学习曲线陡峭平缓中等代码量高中低类型支持手动最灵活仅 C 类型丰富内置 STL/类支持单次调用性能最高有 FFI 开销接近 C APIGIL 控制粒度手动宏自动释放粒度粗RAII 方式粒度细跨 Python 版本需重新编译通常无需重编译需重新编译第三方依赖仅 CPython标准库需要 pybind11 头文件构建工具setuptools 等无直接运行加载setuptools/CMake/Meson构建和分发的差异在实际工程里很要命。C API 和 pybind11 都是编译型扩展构建出来的 .so 和具体 Python 版本强相关Python 3.8 的扩展不能直接拿给 Python 3.11 用通常用 abi3 稳定 ABI 标记才能实现跨版本但配置起来又麻烦。ctypes 因为调的是独立动态库只要 C ABI 稳定理论上一份 .so 可以被多个 Python 版本同时使用分发成本低很多。pybind11 本身是 header-only 库编译时需要包含头文件运行时不依赖第三方动态库绑定代码直接编译进扩展。它和 CMake 的集成是我用过最顺的pybind11_add_module 一个函数就把编译目标定义好了还能自动处理不同平台上的 Python 头文件和链接参数。Windows 上 setuptools 构建 pybind11 扩展会遇到经典的 “Microsoft Visual C 14.0 or greater is required” 报错本质是本地缺 MSVC 构建工具安装 Visual Studio 的“使用 C 的桌面开发”工作负载就能解决。3. 实操对比同一个需求三种写法完整跑通3.1 统一测试案例与环境准备为了让三份实现真有可比性我统一暴露两个函数一个是整数加法 add另一个是字符串拼接问候语 greet。这个案例足够简单方便初学者看结构也足够典型因为参数解析、返回值转换、字符串处理是全都会遇到的场景。我本地的构建环境是 Ubuntu 20.04 Python 3.8 gcc 9。Windows 上的差异我会在对应的注意点里标注。pybind11 我用的是 pip 安装的当前稳定版构建工具链直接用 setuptools。你复现的时候Python 版本和编译器版本略不同问题不大但 pybind11 的 Python 版本一定要和你构建用的解释器一致否则编译出来的扩展模块导入会直接报 ABI 错误。3.2 Python C API手写胶水层的原汁原味先写 C 源文件 capi_demo.c#define PY_SSIZE_T_CLEAN #include Python.h static PyObject* capi_add(PyObject* self, PyObject* args) { int a, b; if (!PyArg_ParseTuple(args, ii, a, b)) { return NULL; } return PyLong_FromLong((long)a b); } static PyObject* capi_greet(PyObject* self, PyObject* args) { const char* name; if (!PyArg_ParseTuple(args, s, name)) { return NULL; } char buffer[256]; snprintf(buffer, sizeof(buffer), hello, %s, name); return PyUnicode_FromString(buffer); } static PyMethodDef CapiMethods[] { {add, capi_add, METH_VARARGS, add two integers}, {greet, capi_greet, METH_VARARGS, greet someone}, {NULL, NULL, 0, NULL} }; static struct PyModuleDef capimodule { PyModuleDef_HEAD_INIT, capi_demo, NULL, -1, CapiMethods }; PyMODINIT_FUNC PyInit_capi_demo(void) { return PyModule_Create(capimodule); }然后是构建脚本 setup.pyfrom setuptools import setup, Extension setup( namecapi_demo, version0.1, ext_modules[ Extension(capi_demo, sources[capi_demo.c]) ] )构建并调用python setup.py build_ext --inplaceimport capi_demo print(capi_demo.add(3, 5)) # 8 print(capi_demo.greet(world)) # hello, world这个例子已经有 50 行左右但注意它只暴露了两个极简单函数。PyMethodDef 数组是手写方法表PyModuleDef 是模块定义PyArg_ParseTuple 负责解包参数。最要命的是每个函数都要手动检查返回值是否为 NULL一旦漏写参数错误时就会直接崩溃而不是抛出 Python 异常。模块初始化函数 PyInit_capi_demo 的名字必须和模块名完全一致差一个字母import 就失败。这些细节不是“知道就行”的级别而是每次写都要特别注意。3.3 ctypes零侵入但需要纯 C 接口ctypes 的核心优势是不动原有 C 代码。但注意这不等于你可以把任意 C 函数直接丢给 ctypes。C 编译器会把函数名做 name mangling比如 add 会变成 _Z3addiiPython 侧写 lib.add 自然找不到。所以 ctypes 方案通常要求库导出的是 C ABI 函数要么本身就是 C 写的要么你在 C 里用 extern C 包一层。下面的 C 代码编译成动态库#include string extern C { int add(int a, int b) { return a b; } const char* greet(const char* name) { static std::string msg std::string(hello, ) name; return msg.c_str(); } }编译g -shared -fPIC -o libctypes_demo.so ctypes_demo.cppPython 侧调用import ctypes lib ctypes.CDLL(./libctypes_demo.so) lib.add.argtypes [ctypes.c_int, ctypes.c_int] lib.add.restype ctypes.c_int print(lib.add(3, 5)) # 8 lib.greet.argtypes [ctypes.c_char_p] lib.greet.restype ctypes.c_char_p print(lib.greet(bworld)) # bhello, world这个例子比 Python C API 短很多是因为所有 C 侧转换都被隔离在了 extern C 外壳里。但代码短不代表没坑argtypes 和 restype 必须写清楚尤其是返回指针的函数如果不设置 restypectypes 默认当 int 处理64 位系统上指针会被截断后续解引用必崩。greet 返回的是 static std::string 的内部指针生命周期靠 static 保证但如果这个函数被多线程并发调用静态变量就会产生数据竞争这是很隐蔽的隐患。ctypes 的字符串是 bytes不是 str传参要传 bworld取值要再 decode。接口一多这些琐碎转换也会累积成不少工作量。3.4 pybind11模板元编程用代码量换体验pybind11 版本的代码看起来完全不像“C 扩展”更像是在写一个普通的 C 模块描述#include pybind11/pybind11.h #include string namespace py pybind11; int add(int a, int b) { return a b; } std::string greet(const std::string name) { return hello, name; } PYBIND11_MODULE(pybind11_demo, m) { m.doc() pybind11 demo module; m.def(add, add, add two integers, py::arg(a), py::arg(b)); m.def(greet, greet, greet someone, py::arg(name)); }注意 add 和 greet 本身完全不用关心 PyObject*也不用操心参数解析和返回值包装。py::arg(a) 让 Python 侧可以直接用关键字调用 add(a3, b5)这是 C API 里做起来比较麻烦的功能。PYBIND11_MODULE 宏会自动生成模块入口函数模块名 pybind11_demo 也必须和最终导入名一致。对应的 setup.pyfrom setuptools import setup, Extension import pybind11 ext_modules [ Extension( pybind11_demo, [pybind11_demo.cpp], include_dirs[pybind11.get_include()], languagec, ) ] setup( namepybind11_demo, version0.1, ext_modulesext_modules, install_requires[pybind11], )构建和调用python setup.py build_ext --inplaceimport pybind11_demo print(pybind11_demo.add(3, 5)) # 8 print(pybind11_demo.greet(world)) # hello, world如果你把这个版本和 Python C API 版本对比会发现 pybind11 把所有“绑定的琐碎”都藏起来了。函数还是那个函数注册就是一行 m.def。字符串自动转换关键字参数自动支持docstring 直接写在参数里。这种体验在简单例子上还不算惊艳一旦遇到类、继承、STL 容器、运算符重载pybind11 的省力程度会指数级上升。3.5 三份实现放在一起差距一眼可见从代码量看C API 用了约 50 行 C 代码ctypes 需要约 15 行 C 外壳加 10 行 Python 声明pybind11 约 20 行 C其中绑定声明只占 4 行。这个差距在只暴露两个函数时是“都可以接受”但如果把这个函数数量放大到 50 个C API 会多出上千行模板代码ctypes 要在 Python 侧维护一份冗长的声明文件pybind11 则只是多 50 个 m.def。从工程体验看C API 是全手动的每一步都在和“检查 NULL”“管理引用计数”搏斗ctypes 省掉了扩展模块的构建但多了 Python 侧和 C 侧两套类型声明的同步负担pybind11 把关注点拉回到“这个函数到底做了什么”而不是“怎么把它包装给 Python”。这就是我为什么强调选型要趁早想清楚——当你接口规模增长之后再换绑定方案成本极高。4. 踩坑实录与排查技巧4.1 Python C API引用计数、GIL 和编码三座大山引用计数是 C API 最大的隐性 bug 来源。扩展里拿到的 PyObject*要分清楚是“借用引用”borrowed还是“新引用”new reference。PyList_GetItem 返回的是借用引用你不能随便释放而 PyLong_FromLong 返回的是新引用用完需要 Py_DECREF。规则本身不复杂但一旦代码规模上来每一处都要手动保证配对漏一个就是内存泄漏或者悬垂指针而且这种 bug 极难定位可能跑几小时才崩一次。PyArg_ParseTuple 的格式串也容易踩雷。格式串 ii 表示两个 int“s” 表示一个 UTF-8 字符串“O” 表示任意对象。写错格式串或者传参类型不匹配时函数返回 NULL但如果你没检查这个返回值继续使用未初始化的变量就是一个漂亮的段错误。这是新手写 C API 最常见的崩溃原因。我的经验是每个 C API 调用函数的返回值都要检查 NULL这不是可选项是硬性纪律。GIL 的问题是另一类典型。如果你在扩展里做耗时的计算而不释放 GIL整个 Python 进程会卡死其他线程全部停摆。正确做法是用 Py_BEGIN_ALLOW_THREADS 在进入重计算前释放 GIL用 Py_END_ALLOW_THREADS 在返回前重新获取。但注意释放 GIL 期间绝对不能再碰任何 PyObject*否则就是未定义行为。这个边界容易犯错尤其在函数中途需要访问 Python 状态时很多初学者会在这里写出运行时随机崩溃的代码。字符串编码也值得一提。PyUnicode_FromString 默认按 UTF-8 解码如果 C 侧字符串是其他编码转换出来就是乱码。更稳的做法是先转成 std::string明确指定编码再构造 Python 字符串或者干脆统一 C 侧输出 UTF-8。这个坑在跨国团队、Windows 环境下的本地化字符串场景里特别明显。4.2 ctypes符号缺失、指针截断和生命周期ctypes 最典型的报错是“找不到符号”。两个常见原因一是 C 文件里忘了写 extern C符号被 name mangling 之后 Python 侧按原名找不到二是动态库编译时没加 -fPIC在 Linux 上或者库不在 Python 可以搜到的路径下。排查方法很简单用 nm -D 查看动态库导出符号确认函数名拼写一致。Windows 上可以用 dumpbin /exports或者用 Python 的 ctypes.util.find_library 辅助定位。第二个高频问题是 64 位指针截断。调用返回指针的函数时如果忘了设置 restypectypes 默认把返回值当 int高 32 位被丢掉Python 侧拿到一个错的地址随后一访问就段错误。这类问题的特点是“不报 Python 异常直接进程崩溃”非常吓人。我自己的习惯是只要函数的返回值不是 int第一行就先把 argtypes 和 restype 写全。生命周期问题也很隐蔽。ctypes 本身不管理 C 对象的内存。如果 C 侧返回一个内部指针比如上面 greet 例子里的 static std::stringPython 侧并不知道它的生命周期约束。如果库被卸载、或者函数在不同线程被调用导致静态变量内容变化Python 侧拿到的指针就会指向不可预期的东西。要规避这个问题最稳的方式是让 C 侧用 malloc 或 new 分配内存同时提供一个配套释放函数Python 侧用完主动调用释放。但这就把“谁分配谁释放”的职责引入到接口文档里沟通成本会增加。4.3 pybind11编译失败、ABI 和对象所有权pybind11 的坑主要集中在编译阶段。Windows 上最经典的就是开头提到的 “Microsoft Visual C 14.0 or greater is required”。这个报错不是 pybind11 本身的问题而是 setuptools 在 Windows 上要调用 MSVC 来编译 C但本机要么只装了老版本要么只装了 MinGW。解决办法是到 Visual Studio Installer 里安装“使用 C 的桌面开发”工作负载把 MSVC v143 生成工具装上。Linux 上则多见于 gcc 版本太老因为 pybind11 需要 C14 支持编译要加 -stdc14。ABI 跨版本问题也要提前打算。pybind11 生成的扩展模块和具体 Python 版本绑定得很紧Python 3.8 编译的 .so 拿到 Python 3.11 环境会直接 import 失败。如果你的团队使用多个 Python 版本要么每版都编译一次要么研究 abi3 稳定 ABI 方案。后者虽然可行但会限制你能使用的部分 Python 内部 API需要权衡。对象所有权是 pybind11 里面最容易出问题的运行时语义。C 侧返回裸指针时pybind11 默认认为它不拥有这个对象Python 侧用完不会自动释放如果实际上这个对象是 new 出来的就会泄漏。反过来如果 C 侧返回内部对象指针但 pybind11 被设置了 take_ownershipPython 侧销毁对象时又会 double free。这个规则需要仔细读 pybind11 文档里的 return_value_policy并且在接口边界上想清楚谁负责释放。用 std::unique_ptr 或 std::shared_ptr 作为返回值往往是更省心的选择。pybind11 的编译速度也是个心病。因为模板实例化量大复杂项目的编译时间可能从几秒拉到几十秒甚至几分钟。这种代价是模板元编程天然带来的没法完全消除。我通常会把绑定的代码单独拆成一个较小的翻译单元减少非绑定代码被反复重编译的情况。4.4 通用的排查工具与调试手段不管选哪条路线下面这些工具和手段都可能救你一命。最基础的是 faulthandler 模块在 Python 里加一行 faulthandler.enable() 或者设置环境变量 PYTHONFAULTHANDLER1段错误时能直接打印出 Python 调用栈很多“莫名崩溃”的问题瞬间就有线索了。Windows 上动态库加载失败先查 os.add_dll_directory 和 PATH。很多 ctypes 调用失败的“隐性问题”其实是依赖 DLL 不在搜索路径里报错信息还特别迷惑。Linux 上可以用 ldd 检查 .so 的依赖用 nm -D 检查导出符号。如果你用的是 C API 或 pybind11gdb/lldb 是不可替代的。Ubuntu 上装 python3-dbg 可以用带调试符号的 Python 运行扩展gdb 里能直接打印 PyObject* 的结构体内容。这个手段对定位引用计数问题和 GIL 相关死锁非常有效。pybind11 还提供了专门的调试支持比如 PYBIND11_DEBUG_MARK 宏可以在关键位置插入标记帮助定位。这些工具平时看着鸡肋真正遇到疑难杂症时每一个都能省下半天时间。5. 最终选型建议5.1 按项目状态快速定位如果让我用最简单的方式总结决策路径大概是下面这套判断逻辑。如果你要对接的是别人已经编译好的动态库自己不需要也不被允许修改构建方式那 ctypes 是首选。你唯一要确认的是对方导出的是 C ABI 接口而不是 C 类、模板或者 STL 类型。如果对方已经开始给你封装 extern C 外壳了说明接口已经跨到了“维护一层薄 C 层”的复杂度那不如直接考虑 pybind11。如果你在持续开发一个 C 库并希望能长期给 Python 团队提供高质量接口pybind11 基本是默认答案。它支持的东西太全面了STL 自动转换、类的完整导出、运算符重载、Numpy 数组零拷贝、还有良好的 CMake 集成。对团队协作来说m.def 加 docstring 的可读性远超 PyMethodDef 方法表新同学接手时上手的成本低得多。如果你要做的是解释器级别的深度定制比如实现嵌入式 Python 宿主、修改内置类型行为、写性能分析器那 pybind11 和 ctypes 都做不到必须回到 Python C API。这种情况下没有捷径只能接受它的复杂度老老实实把引用计数和 GIL 规则学透。5.2 从长期维护角度我最后想说的几句话选型这件事我不太建议大家只看“今天这个需求谁最方便”。接口面大概率会扩大今天只需要两个函数半年后可能就是二十个今天只传 int半年后可能就要传结构体、类、或者 Numpy 数组。如果你一开始选了 ctypes后面接口复杂到包装层失控再迁到 pybind11 的成本肯定比一开始就用 pybind11 高得多。从维护者的心态来讲我最看重的是“代码里有多少内容是业务多少内容是胶水”。Python C API 的问题是胶水占比太高真正做事的代码只有一小半ctypes 是胶水藏在了另一侧Python 声明和 C 头文件的两套真相要时刻同步pybind11 把胶水交给了模板元编程源码里留在你眼前的主要是业务接口本身。这一点在项目迭代半年之后体验差异会非常明显。所以我的总建议是除非你非常明确地知道自己的需求落在 C API 或 ctypes 的独特能力区否则新项目一律默认 pybind11。它不是万能的但它让我在大多数场景下终于可以专心思考 C 算法本身而不是思考怎么把一个指针安全地递给 Python。