ffi.cdef()声明必须严格匹配C签名，否则导致段错误或垃圾值；因CFFI ABI模式不校验参数，仅按声明硬传寄存器/栈，空格、const、字段顺序、指针修饰等均影响兼容性。
ffi.cdef() 声明必须严格匹配 C 签名，否则调用时崩溃或返回垃圾值——这是最常被忽略的硬性前提。
为什么 ffi.cdef() 写错会导致段错误而不是 Python 异常
因为 CFFI 的 ABI 模式不校验函数实际参数个数或类型，只按你写的声明去“硬塞”寄存器或栈。比如把 int add(int a, int b) 错写成 int add(int a)，C 函数仍会从栈上读第二个参数，结果是未定义行为。
- 声明中每个空格、分号、const 修饰符都影响 ABI 兼容性
- 结构体字段顺序、对齐方式（
__attribute__((packed))）必须与 C 编译一致 - 指针类型不能省略：用
char *，别写char；用int *，别写int - 可变参数函数（如
printf）必须用...显式声明，且第一个固定参数不能缺
ffi.dlopen() 加载失败的三种典型路径问题
不是所有 .so 文件都能直接 dlopen 成功，常见卡点在符号可见性、依赖链和路径解析。
- Linux 下若 C 库用了
-fvisibility=hidden编译，导出函数需加__attribute__((visibility("default"))) -
ffi.dlopen("./libmath.so")中的./是相对当前工作目录，不是脚本所在目录；建议用os.path.join(os.path.dirname(__file__), "libmath.so") - 如果库依赖其他 .so（如 libgomp），系统找不到时不会报“找不到 libmath.so”，而是报“undefined symbol”，需用
ldd libmath.so检查依赖树 - macOS 上后缀是
.dylib，且@rpath设置不当会导致加载失败；可用otool -l libmath.dylib | grep -A2 LC_RPATH查看
传递 NumPy 数组给 C 函数时如何避免拷贝
用 ffi.cast() + numpy.ndarray.data.ptr 获取原始内存地址，绕过 Python 层封送开销。
- 确保数组是 C-contiguous：
arr = np.ascontiguousarray(arr, dtype=np.float64) - C 函数声明中用指针类型：
void process(double *data, int n); - Python 侧转换：
ptr = ffi.cast("double *", arr.ctypes.data)，然后传ptr和len(arr) - 切勿用
ffi.new("double[]", arr.tolist())—— 这会复制全部数据，完全失去零拷贝意义 - 若 C 函数修改内存，NumPy 数组会同步更新；无需额外同步操作
ABI 模式 vs API 模式：什么时候必须用 ffi.verify()
ABI 模式（dlopen）快上手但脆弱；API 模式（verify 或 out-of-line build）编译一次，换来类型安全和调试支持。
立即学习“Python免费学习笔记（深入）”；
- 当 C 函数返回结构体、嵌套指针、或需要回调函数时，ABI 模式无法可靠处理，必须用 API 模式
- 使用
ffi.verify()可在 Python 脚本内联写 C 代码，适合原型验证；但生产环境应改用 out-of-line 模式，避免每次 import 都触发编译 - out-of-line 模式下，
ffibuilder.set_source()的第二个参数是 C 源码字符串，可直接#include "myheader.h"，比手动cdef更少出错 - 编译生成的
_cffi_*.so文件要随 Python 包一起分发，不能只靠用户本地有编译器
ctypes 反而更轻量。真正关键的是：C 接口设计是否让 Python 层能批量提交任务，而不是陷入“调用-等待-再调用”的循环。 
