eval()在PHP7.2中执行速度比等效静态代码慢10–30倍，因其每次调用均需完整经历词法分析、语法解析、AST构建与运行时编译，且默认不被OPcache缓存，导致CPU时间不可预测、内存碎片增加、监控失真。
eval() 在 PHP7.2 中的性能开销远超直觉
直接说结论：在 PHP7.2 环境下，eval() 的执行速度通常是等效静态代码的 10–30 倍慢，且每次调用都会触发完整的词法分析、语法解析、AST 构建与运行时编译流程——它不是“跳过编译”，而是每次都从零开始编译。
为什么 eval() 比普通函数调用慢这么多
PHP7.2 的 Zend 引擎虽已大幅优化 opcode 缓存（如 OPcache），但 eval() 生成的代码默认不进 OPcache，除非显式启用 opcache.enable_cli=1（CLI）或配置 opcache.save_comments=1 + opcache.load_comments=1（Web），且即使缓存，也受限于「动态作用域」无法复用。
-
eval()字符串每次都要走完整 Zend parser 流程：tokenize → parse → build AST → compile to opcodes → execute - 普通函数调用只执行已编译好的 opcode，跳过前四步
- 若字符串含语法错误，
eval()报错位置指向eval()调用行，而非字符串内真实出错点，调试成本隐性升高
真实压测对比：一个典型数学表达式场景
假设老项目中大量使用类似 eval("return $expr;") 计算用户传入的简单公式（如 "2 + 3 * 4"）：
- 用
eval()执行 10 万次：约 1.8–2.4 秒（视表达式复杂度） - 改用
array_reduce()+str_split()手动解析（仅支持 +−×÷）：约 0.06 秒 - 改用
symfony/expression-language（预编译 Expression 对象）：约 0.11 秒，且支持变量注入与类型安全
差距不是毫秒级，而是整数量级。更关键的是：eval() 的 CPU 时间不可预测——遇到嵌套括号或非法字符时，parser 会反复回溯，毛刺明显。
立即学习“PHP免费学习笔记（深入）”；
容易被忽略的间接损耗
性能问题不止在单次执行：
- OPcache 会为每个
eval()字符串生成独立的 cache key，极易引发 cache pollution，挤占真正高频脚本的缓存空间 - PHP-FPM worker 进程中，大量
eval()导致内存碎片增加，GC 压力上升，可能提前触发进程重启 - APM 工具（如 New Relic、Tideways）对
eval()的采样常丢失上下文，监控里只显示“unknown eval”，掩盖真实瓶颈点
替换掉 eval() 不只是堵住安全漏洞，更是把一块长期卡在引擎底层的“减速带”拿掉——尤其在 PHP7.2 这种已停止主流支持、缺乏 JIT 优化的老版本上，这点尤为明显。
