eval() 极度危险，仅限无外部输入场景；安全替代方案是闭包绑定变量、反射仅用于调用已有函数、生产环境应通过文件写入+composer自动加载实现动态函数。
eval() 能动态创建函数，但极度危险
绝大多数场景下，eval() 是唯一能“运行字符串生成函数”的 PHP 原生手段，但它会直接执行任意代码——只要用户可控输入进了 eval()，就等于把服务器控制权交出去。哪怕加了 strip_tags() 或正则过滤，也挡不住绕过。
常见错误现象：ParseError: syntax error, unexpected 'function'（漏写分号或括号）、Undefined function（作用域问题）、更糟的是被植入 system('rm -rf /')。
- 只在完全可信的配置文件、离线代码生成等**无外部输入**场景中考虑它
- 必须确保字符串里不含任何用户提交内容，包括 GET/POST/COOKIE/$_SERVER 里的字段
- PHP 8.1+ 中
eval()在 OPcache 启用时可能被跳过优化，行为不一致
闭包 + 变量绑定是安全的动态函数构造方式
真正实用的动态函数生成，靠的是 function 关键字声明闭包，并用 use 绑定外部变量——它不拼字符串，不触发解析器重入，天然免疫代码注入。
使用场景：根据配置生成验证器、按字段名动态构造 getter、批量注册事件回调。
立即学习“PHP免费学习笔记（深入）”；
示例：
$field = 'email';
$validator = function ($value) use ($field) {
return filter_var($value, FILTER_VALIDATE_EMAIL) ?: "$field is invalid";
};
-
use绑定的是值拷贝，如需引用修改，得写use (&$var) - 闭包无法直接命名，若需多次复用，应赋给变量或存入数组：
$rules['email'] = $validator; - 性能上和普通函数几乎无差，PHP 7.4+ 对闭包的 JIT 编译已很成熟
反射 API 不能动态创建函数，但能动态调用
有人误以为 ReflectionFunction 或 ReflectionMethod 能“生成”函数，其实它们只是读取已有函数的元信息。你不能用反射凭空造出一个函数实体。
容易踩的坑：new ReflectionFunction('nonexistent') 会抛出 ReflectionException，不是返回 false；且反射对象本身不执行逻辑，只是描述工具。
- 适合做函数签名校验、参数类型检查、文档提取
- 动态调用已有函数请用
call_user_func()或invoke()，别绕路反射 - PHP 8 的
#[\Attribute]配合反射可实现注解驱动的行为，但这仍基于预定义函数
Composer 自动加载 + 文件写入是生产环境可行方案
当真需要“运行时决定函数内容”，比如低代码平台生成业务逻辑，正确做法是：拼好 PHP 代码 → 写入临时文件 → 通过 Composer 的自动加载机制引入。这比 eval() 安全得多，还能被 OPcache 缓存。
关键点在于路径和命名空间必须严格符合 PSR-4 规范，否则 require 进来也无法被识别为类或函数。
- 生成的文件必须以
.php结尾，且顶层只能有函数声明或return语句（不能混用） - 推荐用
file_put_contents($path, $code, LOCK_EX)避免并发写乱 - 写完后需调用
Composer\Autoload\ClassLoader::addPsr4()或重建 autoload map（开发期可composer dump-autoload）
复杂点在于文件权限、OPcache 失效时机、以及错误时的清理逻辑——这些不是语法问题，而是工程边界问题，稍不留神就会卡在“改了代码却没生效”。
