PHP eval 定义函数风险大，慎用！

PHP 中使用 `eval()` 定义函数看似只是声明逻辑，实则等同于无隔离、无沙箱的任意代码执行——只要输入可控（如来自请求参数、数据库或文件），攻击者即可注入并立即执行危险操作，如删除系统文件或写入 Webshell；`assert()` 的字符串模式同样危险，尤其在调试配置未关闭的生产环境中；所有基于字符串拼接的“过滤”或“封装”方案（如 `create_function`、正则过滤）均不可靠，真正安全的替代路径是采用白名单校验、预定义回调、匿名函数工厂、反射调用或结构化 DSL 解析，将动态逻辑转化为受控的数据驱动行为，既杜绝 RCE 风险，又保障可维护性与跨版本兼容性。

eval() 里用 function 定义函数 = 直接执行任意代码

不是“不安全”，是根本没隔离——eval() 的字符串在当前作用域完整执行，function 声明会立刻注册到运行时环境中，和手写函数完全等价。只要输入可控（比如来自 GET、POST、数据库、文件），攻击者就能注入 system('rm -rf /')、file_put_contents('/var/www/shell.php', $_GET['p']) 这类语句。

常见错误现象：eval("function foo() { return 'ok'; }"); foo(); 看似只是定义函数，但若前面字符串被拼接了恶意逻辑（如 "function foo(){...}; unlink('/etc/passwd');"），就已触发危害。

• 别信“我只拼接固定前缀 + 用户输入的函数名”——函数名可被闭合后追加代码
• 别用 preg_replace 过滤关键词——绕过方式太多（大小写、编码、注释符、变量拼接）
• PHP 8.1+ 的 eval() 仍无沙箱机制，禁用 disable_functions 也拦不住内存中直接调用系统 API

替代方案：用 create_function()？别，它更糟

create_function() 已在 PHP 7.2 废弃、8.0 移除，本质就是对 eval() 的封装，还额外引入字符串拼接风险。它的参数是两个字符串：create_function('$a,$b', 'return $a + $b;')，第二参数照样进 eval，且闭包作用域更难审计。

使用场景里唯一“看似合理”的动态回调（比如配置里存函数体），实际应改用：

• 预定义函数列表 + 白名单校验：in_array($func_name, ['add', 'multiply'], true)
• 匿名函数工厂：$funcs = ['add' => fn($x, $y) => $x + $y]; $funcs[$input] ?? null
• 反射调用已声明方法：(new Calculator)->{$method}(...$args)，前提是 $method 经严格过滤

真要动态生成函数？走 opcode 编译路径，而非 eval

PHP 扩展如 FFI（PHP 7.4+）或 ast（需编译安装）能解析 AST 并校验结构，但门槛高、维护重。更现实的是：把“动态函数”转为数据驱动逻辑。

例如规则引擎场景，不要 eval("return \$_POST['a'] > \$_POST['b'] && \$_POST['c'] === 'yes';")，而是：

• 定义 DSL（如 JSON 规则：{"op": "and", "left": {"op": "gt", "args": ["a", "b"]}, "right": {"op": "eq", "args": ["c", "yes"]}}）
• 用白名单操作符映射到 PHP 函数：$ops['gt'] = fn($x, $y) => $x > $y;
• 递归解释执行，全程不触碰 eval 或 assert

性能影响几乎可忽略；兼容性上，DSL 解析器比依赖 eval 的代码更容易跨版本迁移。

误用 assert() 当 eval() 用？同样危险

PHP 7.2+ 默认关闭 assert() 的字符串执行模式，但若项目显式设了 ini_set('assert.exception', 0); ini_set('assert.active', 1);，且传入字符串，assert("system('id')") 就等同于 eval()。

错误现象：本地开发开 assert 调试，上线忘记关，或依赖框架默认配置（如旧版 Laravel 的 debug 模式）。

• 永远用布尔表达式：assert(is_int($x) && $x > 0)，别传字符串
• 生产环境强制关闭：assert_options(ASSERT_ACTIVE, 0)，或设 zend.assertions = -1（OPcache 级别禁用）
• 检查 phpinfo() 输出中 assert.active 和 zend.assertions 的实际值，别只信配置文件

真正难防的不是语法错误，是开发者以为“我只是在定义一个函数”，却忘了 eval() 从不区分定义和执行——那行字符串进来那一刻，就已经在你的进程里跑起来了。

理论要掌握，实操不能落！以上关于《PHP eval 定义函数风险大，慎用！》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！