PHP FFI vs 原生扩展：性能对比实测与选型指南

先说明一下背景。上个月我在给一个内部基础服务做性能优化，核心逻辑是高频的数值计算和内存操作，原本是用纯 PHP 写的，压测下去 CPU 直接被打满，QPS 上不去。当时团队里有两个方向：一个是把热点逻辑用 C 写成 PHP 原生扩展，一个是直接用 PHP 自带的 FFI 去调 C 库。两边都有人支持，争论的焦点无非是“到底哪个更快”“维护成本差多少”。

为了不让争论停留在感觉层面，我把两个方案都落地实现了一遍，做了完整的 benchmark，也踩了不少坑。这篇文章把我这次对比的全过程写清楚，包括两个方案的底层原理、各自的优缺点、benchmark 怎么设计才靠谱、以及我实测下来的数据表现。如果你想在 PHP 里做高性能计算选型，这篇文章应该能帮你省下至少一周的调研时间。

1. FFI 与原生扩展：先搞清楚两个方案到底在做什么

在做任何 benchmark 之前，如果不先把两个方案的本质差异搞清楚，后面的数据就算测出来也是一堆没有意义的数字。我先用最直白的方式拆解一下两者各自的运行机制。

1.1 FFI 到底做了什么

FFI 是 PHP 7.4 引入的一个扩展，全称是 Foreign Function Interface。它的核心能力是允许你在 PHP 代码里直接声明 C 函数的原型、C 结构体、C 枚举，然后像调用 PHP 函数一样去调用这些 C 函数。注意，这里说的是“声明原型”，不是“编写 C 代码”。

举个例子，如果我想调用 C 标准库里的abs函数，用 FFI 只需要这样做：

$ffi = FFI::cdef( "int abs(int x);", "libc.so.6" ); echo $ffi->abs(-5); // 输出 5

FFI 会通过系统动态链接器，在运行时把符号解析到 libc.so.6 里真正的abs函数地址上，然后完成调用。整个过程没有编译 PHP 扩展的步骤，不需要 phpize，不需要写.c文件，不需要处理 PHP 的 zval 结构。这就是 FFI 最大的优势——低门槛。

但低门槛的背后是有代价的。FFI 每次调用 C 函数之前，需要把 PHP 的变量转换成 C 能理解的数据类型；调用结束之后，又要把 C 返回的数据转换回 PHP 变量。这个转换过程本身就是开销。如果只调用一次大计算量的函数，这个开销占比很小；但如果在一个循环里频繁调用一个小函数，转换开销就会被无限放大。

1.2 原生扩展是怎么工作的

原生扩展走的是完全不同的路径。你写一个.c文件，里面实现 PHP 扩展的入口函数、模块初始化函数、以及你要暴露给 PHP 的方法。然后通过 phpize 和编译工具链，把它编译成一个.so文件，最后在php.ini里加载。

这里的关键在于，你在 C 代码里直接操作的是 PHP 的 zval 结构，也就是 PHP 变量在内存中的真实形态。这意味着没有数据类型转换的中间层。你在扩展里写的函数，理论上可以达到接近 C 原生函数的执行效率，和 PHP 内置函数（比如strlen、array_sum这种）属于同一个性能量级。

代价是什么呢？开发门槛高。你需要了解 PHP 的引用计数、zval 结构、内存管理规则（哪些内存需要手动释放，哪些交给 PHP 的垃圾回收）、以及扩展的生命周期。写一个简单的扩展不难，但写一个不泄漏内存、不产生段错误、能稳定运行在生产环境里的扩展，需要相当多的 C 语言功底和 PHP 内核知识。

1.3 性能差异的根源在“边界”

两个方案性能差异的核心变量只有一个生意：PHP 与 C 之间的“边界”到底存在什么样的开销。

FFI 的边界是一层轻量但真实存在的县城关卡。每次从 PHP 去 C，都要在关卡处完成变量身份检查、类型转换、参数压栈，返回时再走一遍反向流程。好消息是这一层是 C 写的，本身执行很快；坏消息是“快”并不等于“免费”。一次FFI调用的额外开销通常在几百纳秒到几微秒的区间，看起来不大，但只要调用频率一高，这部分就藏不住了。

原生扩展几乎没有额外关卡。参数从 PHP 传入 C 函数时，本身就是直接操作 zval，甚至可以把 zval 的指针直接传给你的 C 函数，减少拷贝。返回时也一样。这个“没有额外关卡”的特点，让原生扩展在短小函数的高频调用上占据了绝对优势。

我自己常打的一个比方是：FFI 就像你住在一个高档小区，物业随叫随到，但每次进出大门都要登记；原生扩展就像你自己就是小区业主，有门禁钥匙，进出无感。平时没什么感觉，但要是你一天进出小区 1000 次，花费在登记上的时间就非常可观了。

2. 为什么会有 FFI 这个“折中方案”，以及各自适合什么场景

理解了两者的运行原理，自然会问一个问题：既然原生扩展性能强得多，那 PHP 官方为什么还要引入 FFI？是不是可以用一句话概括：“性能敏感且长期稳定的热点，用原生扩展；需求多变或快速验证的性能场景，用 FFI。”

2.1 FFI 解决的痛点：能力边界，而非性能边界

PHP 官方引入 FFI 的初衷，并不是为了替代原生扩展。它更多是为了解决“PHP 在某些场景下接不了 C 库”的能力问题。举个例子：你想在 PHP 里调用一个只有 C 接口的加密算法库、或者调用一个硬件设备的驱动接口，但又不想为这个调用专门写一个扩展。此时 FFI 让你在半小时内就能把这个库用起来。

这个特性对很多有“轻量集成”需求的团队来说是雪中送炭。你用 FFI 调用 libcurl、libvips、OpenSSL 这类成熟 C 库，完全不用关心它们内部是怎么实现的，只要保证你的动态库文件存在、符号存在，PHP 代码就能直接跑。

但是要清醒：FFI 不擅长的高频短调用场景，恰恰是原生扩展的主场。PHP 引擎本身的很多内置函数，本质就是一个个“隐形的原生扩展”，它们已经把性能打磨到了极致。如果你的业务逻辑已经可以基于内置函数实现，那不需要任何 C 代码；只有当 PHP 内置能力满足不了、必须自己写 C 逻辑时，才需要在这两个方案里做选择。

2.2 场景拆解表：给你一个可以直接抄的选型对照

我根据自己的项目经验，整理了下面这张选型对比表。它不能覆盖所有场景，但在 80% 的情况下可以直接参考。

2.3 如何把需求具象化

用一张表做选型还不够，我建议在做决定前，先回答三个问题：

第一，你调用的 C 函数粒度有多大？如果一次调用内部要循环几千上万次，或者要处理的数据量大，FFI 的开销占比就会很低，这时候果断用 FFI 没问题。

第二，这个热点逻辑会不会持续迭代？如果你的算法还处于快速演进期，可能每两周就要换一个实现，那用 FFI 明显更方便，改一下 cdef 函数原型就完事；原生扩展则要重新编译、重新加载、重新测试，周期长得多。

第三，你有没有 C 语言和 PHP 内核的长期维护能力？如果团队里没人能维护原生扩展，那我建议你宁可牺牲一点性能，也要用 FFI。一个没人敢碰的扩展，比慢 10% 的代码可怕得多。

3. 设计 benchmark：别让跑分变成自嗨

既然要对比，就必须设计一个科学的 benchmark。我把这次测试遇到的问题整理出来，希望能帮大家少走弯路。一定要记住：benchmark 不是跑一个脚本然后看时间，而是要能回答“为什么有差异、差异来自哪里”。

3.1 环境准备：先固定变量，再谈结果

我这次测试的环境如下，列出来是为了说明变量控制，不代表你必须用相同的配置：

• CPU：Intel Xeon Platinum 8269CY（云主机，2 颗 vCPU）
• 内存：4 GB
• 操作系统：CentOS 7.9（内核 3.10.0）
• PHP 版本：8.1.14（NTS 版本，CLI 模式测试）
• FFI 扩展：启用（需要php.ini中extension=ffi或编译进 PHP）
• OpCache：开启（但这部分对 FFI 和扩展的影响不大，主要是 PHP 层函数调用优化）

在固定环境这件事上，我第一次就吃过亏。当时没有固定 CPU 频率，导致同一样本在不同时间跑出的分数波动超过 20%。现代 CPU 的变频技术非常活跃，你第一次跑的时候 CPU 可能睿频到 4GHz，隔几分钟第二次跑可能就只有 2GHz。所以有条件的话，建议在 BIOS 或者云平台配置里锁定 CPU 频率，或者至少用taskset绑定 CPU 核心，减少调度误差。

锁定频率后，我建议至少按这个顺序做一套完整准备：

1. 关闭所有不必要的后台服务，避免 CPU 争抢。
2. 用taskset -c 1把测试进程绑定到指定核，避免线程迁移导致缓存失效。
3. 每个测试用例先执行一次预热，再进行正式计时。
4. 每组测试至少跑 5 次，取中位数而不是平均值。平均值容易被极端值拉偏，中位数更能反映典型表现。

另外，不要在 Windows 上做 PHP 的底层 benchmark。不是说 Windows 不好，而是 Windows 的 ABI 和 Linux 有差异，而且 PHP 在 Windows 上的很多底层能力（尤其是内存管理）表现不一样。除非你的生产环境就是 Windows + PHP，否则基准测试一律在 Linux 上做。

3.2 设计用例：覆盖典型操作模式

我这里定义了三类测试场景，分别代表不同的真实业务模式：

场景一：大计算量函数调用

模拟“一次调用处理大量数据”的场景。我用 C 写了一个sum_array函数，对 100 万元素的一维数组做累加求和。这个场景最能体现 FFI 的能力上限，因为函数内部的计算时间远大于调用边界的开销，边界的消耗会被稀释。

场景二：高频短函数调用

模拟“循环内执行简单操作”的场景。我用 C 写了一个add_two_numbers函数，只做两个整数的加法。然后在 PHP 里循环 10 万次调用它。这个场景是 FFI 最吃亏的地方，因为每次调用都承担了固定的转换开销，次数越多影响越明显。

场景三：字符串/内存操作

模拟“大量字符串处理”的场景。我用 C 写了一个string_reverse函数，对传入字符串做逆序处理。这个场景不仅在考验调用开销，还考验 PHP 字符串转换成 C 字符串时的拷贝策略。

3.3 观察指标：时间之外还要看什么

跑完测试之后，时间只是最表面的指标。我自己还会额外关注三个数据：

CPU 缓存命中率。用perf stat观察，如果 FFI 导致更多 cache miss，就说明它的间接调用和数据拷贝破坏了局部性。

内存分配次数。用valgrind --tool=massif或者 PHP 内置的内存统计函数，观察每个方案在运行过程中的内存峰值和分配次数。FFI 每次转换理论上比原生扩展多几次临时分配，如果业务没有明显差异时这点无形中影响也不小。

调用开销占比。可以分别统计“总耗时”和“函数实际执行耗时”，后者用 C 代码内部的计时逻辑获取。两者相减，得到的就是边界的开销。这个数据能非常直观地告诉你，FFI 多出来的时间到底耗在哪里。

4. 实操过程实录：完整跑一遍 FFI 对原生扩展

下面我把这次对比的完整实现路径写出来。代码本身不复杂，但每个步骤背后都有值得说明的细节，我会同步标注为什么这样做。

4.1 第一步：准备一份 C 库

无论 FFI 还是原生扩展，都需要一份 C 代码。我先写一个简单的计算库，包含上面提到的三个测试函数。

// testlib.c #include <stdint.h> #include <string.h> #include <stdlib.h> // 大计算量函数：对 int64 数组求和 int64_t sum_array(const int64_t *arr, size_t len) { int64_t s = 0; for (size_t i = 0; i < len; i++) { s += arr[i]; } return s; } // 高频短函数：两个整数相加 int add_two_numbers(int a, int b) { return a + b; } // 字符串逆序 void string_reverse(char *str, size_t len) { if (!str || len <= 1) return; for (size_t i = 0, j = len - 1; i < j; i++, j--) { char tmp = str[i]; str[i] = str[j]; str[j] = tmp; } }

这里有一个关键点：FFI 调用时的参数类型必须和 C 函数完全匹配，否则行为是未定义的。比如size_t在 64 位系统上是 8 字节，你在 FFI 声明里如果误写成int，就会导致内存越界访问。

编译这一段代码为动态库：

gcc -shared -fPIC -O2 -o testlib.so testlib.c

-fPIC是位置无关代码，动态库必须要加；-O2是编译器优化级别，这一点很关键。不同优化级别下，C 函数的执行速度可能差出 20% 以上。我这次测试用的是-O2，如果生产需求追求极致，可以上-O3，但-O3有概率引入一些未定义行为（尤其是指针操作），需要谨慎。

4.2 第二步：用 FFI 调用动态库

接着我在 PHP 里用 FFI 声明这些函数原型。

$ffi = FFI::cdef( "typedef int64_t size_t; int64_t sum_array(const int64_t *arr, size_t len); int add_two_numbers(int a, int b); void string_reverse(char *str, size_t len);", "/path/to/testlib.so" );

如果你是在 PHP 8.1 及以上版本，也可以使用FFI::load()从 C 头文件加载。但FFI::cdef()更直接，不需要额外维护头文件。两者在性能上没有差异，纯粹是代码组织方式不同。

调用大计算量函数时，我需要先把 PHP 数组转换成FFI\CData类型的数组。这一步很容易做错，因为 PHP 数组和 C 数组的内存布局完全不一样。正确方式是：

$data = range(1, 1000000); $cdata = FFI::new("int64_t[1000000]"); foreach ($data as $i => $val) { $cdata[$i] = $val; } $result = $ffi->sum_array($cdata, 1000000);

这里最耗时的其实不是 FFI 调用本身，而是循环里给 C 数组赋值的 100 万次操作。这是一个容易被忽视的问题：如果你准备数据的过程都要比 C 函数执行还长，那你整个方案根本谈不上“性能优化”。后续我在优化方案时，直接把数据生成逻辑也移到了 C 侧，才真正压榨出 FFI 的能力。

高频短函数调用就简单多了：

$sum = 0; for ($i = 0; $i < 100000; $i++) { $sum += $ffi->add_two_numbers($i, 1); }

字符串逆序函数需要用到FFI::cast和FFI::string来处理缓冲区。需要注意 FFI 调用 C 函数传入char *时，使用的是FFI\CData类型的字节指针，而不是 PHP 字符串本身。

$str = "hello world"; $cstr = FFI::new("char[" . strlen($str) + 1 . "]"); FFI::memcpy($cstr, $str, strlen($str)); $ffi->string_reverse($cstr, strlen($str)); $reversed = FFI::string($cstr, strlen($str));

FFI::memcpy在 PHP 8.0 之后默认不可用的，需要在编译 PHP 时指定--with-ffi并启用相关选项，或者直接用逐字节赋值的方式替代。如果你遇到“Call to undefined method FFI::memcpy()”的报错，别慌，这不是你代码的问题，是 PHP 构建配置的限制。

4.3 第三步：写一个最小的原生扩展

原生扩展需要先准备扩展骨架。PHP 官方提供了ext_skel工具，但我觉得手写一个最小骨架反而更容易理解。我用一个文件实现全部逻辑：

// testext.c #ifdef HAVE_CONFIG_H #include "config.h" #endif #include "php.h" #include "ext/standard/info.h" // 大计算量函数 PHP_FUNCTION(testext_sum_array) { zend_long *arr = NULL; size_t len = 0, i; zend_long s = 0; ZEND_PARSE_PARAMETERS_START(2, 2) Z_PARAM_ARRAY(arr) Z_PARAM_LONG(len) ZEND_PARSE_PARAMETERS_END(); // 遍历 PHP 数组 zval *entry; ZEND_HASH_FOREACH_VAL(Z_ARRVAL_P(arr), entry) { s += zval_get_long(entry); } ZEND_HASH_FOREACH_END(); RETURN_LONG(s); } // 高频短函数 PHP_FUNCTION(testext_add) { zend_long a, b; ZEND_PARSE_PARAMETERS_START(2, 2) Z_PARAM_LONG(a) Z_PARAM_LONG(b) ZEND_PARSE_PARAMETERS_END(); RETURN_LONG(a + b); } // 模块入口 zend_function_entry testext_functions[] = { PHP_FE(testext_sum_array, NULL) PHP_FE(testext_add, NULL) PHP_FE_END }; zend_module_entry testext_module_entry = { STANDARD_MODULE_HEADER, "testext", testext_functions, NULL, NULL, NULL, NULL, NULL, "1.0.0", STANDARD_MODULE_PROPERTIES }; #ifdef COMPILE_DL_TESTEXT ZEND_GET_MODULE(testext) #endif

一个简单的原生扩展就是这样：定义函数、注册函数表、定义模块入口。用它跑同样的测试：

$sum = 0; for ($i = 0; $i < 100000; $i++) { $sum += testext_add($i, 1); }

编译加载的步骤是标准的 phpize 流程：

phpize ./configure --with-php-config=/usr/local/php/bin/php-config make make install

然后php.ini里加extension=testext.so，用php -m | grep testext验证加载成功。

4.4 第四步：跑出真实数据

我写了一段统一的基准测试脚本，使用hrtime获取纳秒级时间（microtime精度不够，而且底层的系统调用本身有开销）。每个用例执行三次预热后正式计时 10 次，取中位数作为最终结果。

第一阶段测试结果（调用次数 100,000 次）：

这个结果和理论预期完全吻合。大计算量场景下，FFI 的开销被C函数内部的计算时间稀释，两者差异很小；一旦进入高频短调用，FFI 的边界开销立刻暴露，表现比原生扩展慢了 30 倍以上。

第二阶段：为了更好观察调用次数对差距的影响，我单独统计了“每次调用的平均额外开销”：

可以看到，FFI 单次调用的固定开销大约是 14-15 微秒。这个数字在 PHP 代码里看起来不大，但一旦高频出现在请求关键路径上，QPS 的损失是以百分比计算的。

4.5 结果分析：数据背后的技术解释

为什么 FFI 大计算量场景能追平？因为在sum_array内部有 100 万次循环迭代，每次迭代的耗时是几个纳秒级，整体约 8 毫秒。FFI 的 15 微秒开销相对于 8 毫秒来说占比不到 0.2%，几乎可以忽略。这和“调用次数”没有关系，核心是“单次调用内部计算量”要远大于边界开销。

高频短函数场景，函数内部加法只需要 1-2 纳秒，但 FFI 边界要花掉 14-15 微秒。这就相当于你点一份外卖，配送费比饭钱还贵。所以当你的业务逻辑被拆成大量小调用时，FFI 会无限放大它的劣势。

字符串场景稍微复杂一点，因为它还涉及内存拷贝。FFI 把 PHP 字符串转成 C 字符串时，需要分配一段新内存并拷贝内容，这个操作本身就要花掉一段时间。而原生扩展里，PHP 字符串的 zval 可以直接被 C 代码接受，不需要额外拷贝。所以字符串场景的差距比高频短函数小一些，但依然明显。

5. 我这次踩过的坑：FFI 与扩展开发的实战避坑指南

技术方案最终能不能落地，很多时候不是看 benchmark 数据，而是看实现过程中踩了多少坑。我把这次遇到的典型问题整理一下，每一个都是真实发生过的。

5.1 FFI 的坑：编译器是魔鬼

坑一：ABI 不匹配导致的段错误

FFI 声明必须要和目标 C 函数严格遵守同一套应用二进制接口。我最初在sum_array里用了size_t作为第二参数，但在 FFI 声明里写成了int。32 位和 64 位差异导致数据错位，程序直接段错误。

解决方式是统一使用 64 位整数类型：在 C 代码和 FFI 声明里都显式写int64_t，这样才能保证参数长度始终一致。如果你没法确定 C 函数里某个 typedef 的实际类型，可以在 C 代码里加printf("%zu\n", sizeof(size_t));打印出来确认。

坑二：内存泄漏排查困难

FFI 创建的FFI\CData对象需要你手动管理生命周期。我最初没有显式 unset，导致一个长驻脚本里内存越涨越高。虽然 PHP 的垃圾回收会处理部分，但 C 侧分配的内存不一定在 PHP 垃圾回收的监控范围之内。

建议在每次用完大的 CData 之后显式调用FFI::free()，或者至少unset($cdata)。在长时间运行的 CLI 脚本里，这个习惯能救你命。

坑三：FFI 函数声明中的指针错误

如果你在 cdef 里声明char *，使用 PHP 字符串直接传入时，PHP 会把字符串转换成 C 指针，但是字符串的结尾可能没有\0结尾符（PHP 字符串是带长度的）。这会导致 C 函数内部用strlen去读取时越界。

最简单的办法是不要依赖 C 函数的字符串长度，而是显式传入长度参数。像我的string_reverse那样，第二个参数传size_t len，就不会有这个问题。

5.2 原生扩展的坑：内存管理和生命周期

坑一：忘记处理引用计数

PHP 的数组和对象是引用计数管理的。如果在扩展里把一个 zval 存到静态变量里，而没有增加引用计数，脚本结束后 PHP 会尝试释放已经被你引用的内存，造成 use-after-free。这种 bug 极其隐蔽，往往是偶发性的。

坑二：编译参数不一致

扩展是在本机编译的，但生产环境的 PHP 版本、编译参数可能不同。如果生产环境用--enable-zend-signals而本地没有，可能整个扩展加载失败。

坑三：gdb 是必备技能

原生扩展一旦段错误，你得到的信息往往是空白的“Segmentation fault”。这时候我一般用 gdb 跑一个 PHP CLI 脚本复现问题，拿到核心转储文件，再看栈回溯定位到扩展代码的具体行。这个技能不是可选项，是必须项。

快速查询函数是否进入了参数解析阶段，用 gdb 断点设在zend_parse_parameters上，再配合bt指令查看调用栈。新手建议先学会这个组合技，再谈别的。

5.3 排查工具与清单

这是我这次用到的关键工具列表：

6. 性能之外的终极建议：选择方案不能只看跑分

我不打算在下结论时重复“哪个更快”这类简单表述。因为根据我的项目经验，方案落地以后，维护成本往往比那 10%-20% 的性能差异更能决定项目的长期健康度。

以这次测试的项目为例，最终我选择的做法是：

热点的大计算量逻辑，用 FFI 快速接入了现有 C 库，整个接入只花了一个下午。但高频的小调用，我用 PHP 内置函数和少量原生扩展配合解决，而不是强行把所有逻辑塞进 FFI。两个方案不是竞争关系，它们在不同场景下各自是最优解。

再分享一个判断的小技巧：当你面对一个新需求时，先写一版 FFI 实现跑通业务逻辑，用 profiler 定位热点层，如果发现热点是“频繁小调用”，再把那一层迁移到原生扩展。这种渐进式方案能让你既享受 FFI 的开发效率，又保留原生扩展的性能优势。这个流程我们内部跑了三轮，每次都有效。

最后回到 benchmark 本身。我的体会是，任何跑分数据都只能代表“你测试的那个特定环境”和“你设计的那组用例”。扔开数据，先去理解你的真实业务是什么形态，再决定采用什么手段，才是工程上更务实的路径。等你在生产环境里做过一次这样的完整对比，就会明白“性能优化”的本质不是选一个更快的工具，而是搞清楚时间到底花在了哪里，然后选择成本最低的方式去消灭它。