eval() 中用 function 定义函数本质是直接执行任意代码，无任何隔离机制，输入可控即导致远程代码执行；应禁用 eval 和 assert 的字符串模式，改用白名单、dsl 或预定义回调等安全方案。
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，且闭包作用域更难审计。
使用场景里唯一“看似合理”的动态回调（比如配置里存函数体），实际应改用：
立即学习“PHP免费学习笔记（深入）”；
- 预定义函数列表 + 白名单校验：
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() 从不区分定义和执行——那行字符串进来那一刻，就已经在你的进程里跑起来了。