在绝大多数业务场景下，PHP函数调用本身开销极小，基本可忽略；真正影响性能的是函数内部操作、动态调用、反射类函数及未优化的自定义函数。
PHP函数调用真有明显开销吗？
在绝大多数业务场景下，function 调用本身开销极小，基本可忽略。PHP 7+ 的引擎对普通函数调用做了大量优化，一次 strlen() 或 is_array() 调用耗时通常在纳秒级。真正拖慢性能的，往往是函数内部做的事儿——比如 file_get_contents() 读大文件、preg_match() 处理超长文本、或层层嵌套的递归调用。
哪些函数调用值得警惕？
以下几类调用在循环中反复出现时，容易成为瓶颈：
-
date()、time()：系统调用 + 格式化开销，尤其在高并发日志写入时 -
func_get_args()、debug_backtrace()：反射类操作，开销比普通函数高10–100倍 - 未声明返回类型的自定义函数（尤其带引用参数或异常处理逻辑的）：JIT 优化效果差
- 通过
call_user_func()或__call()动态触发的调用：绕过编译期绑定，无法内联
怎么安全地“去掉”函数调用？
不是所有函数都能/都应该内联，关键看是否满足三个条件：逻辑稳定、无副作用、参数可控。实操建议如下：
- 简单判断类函数（如
empty()、isset()）不用动——PHP 已深度优化，手动展开反而破坏可读性 - 高频字符串处理（如循环里反复
substr($s, 0, 1)）可改用$s[0]（PHP 7.4+ 支持）或$s{0}（旧版），但需确认$s非空 - 时间相关逻辑，把
date('Y-m-d')提到循环外缓存；若需毫秒级精度，改用hrtime()（PHP 7.3+）避免microtime(true)的浮点转换成本 - 绝对不要为了省一次调用去复制粘贴复杂函数体——调试难度和维护成本上升远超那几纳秒
OPcache 和 JIT 开启后还用管函数调用吗？
要管，但重点变了。OPcache 缓存编译后的字节码，JIT（PHP 8.0+ 默认启用）能将热点函数编译为机器码，但它们都依赖「可预测的执行路径」：
立即学习“PHP免费学习笔记（深入）”；
- JIT 对含
eval()、动态函数名（如$fn()）、或频繁改变签名的函数基本不生效 - OPcache 不会合并不同作用域下的同名函数（比如两个文件都定义了
helper()），重复定义反而增加内存占用 - 开启
opcache.enable_cli=1后，CLI 脚本的函数调用性能才真正接近 Web 请求，这点常被忽略
最常被漏掉的是：JIT 默认只对执行超过一定次数的函数触发编译，而本地开发环境请求少，可能根本没机会触发——别光看配置开了没，得看 opcache_get_status()['jit']['enabled'] 和 ['jit']['compiled_functions'] 实际值。
