eval不能防错，只能避免使用；它是php代码解释器入口，会绕过类型检查、跳过autoloader、触发任意代码执行，且parseerror和fatal error无法被try-catch捕获。
eval 函数根本不能“防错”，只能“避免用”
直接说结论：eval 不是普通函数，它是把字符串当 PHP 代码执行的“解释器入口”。一旦出错，不是报个 ParseError 就完事——它可能绕过所有类型检查、跳过 autoloader、甚至触发任意代码执行。所谓“防止错误”，本质是拒绝让它运行。
为什么 try-catch 拦不住 eval 的致命问题
try/catch 只能捕获运行时异常（Exception），但 eval 中的语法错误会抛出 ParseError（PHP 7+）或直接 fatal error（PHP 5），这两者都不继承自 Exception，无法被常规 catch 捕获。
常见错误现象：
- 写
eval("echo $user_input;");，用户输"); system('rm -rf /');→ 直接执行命令 - 写
eval("return $config['host'];");，但$config未定义 →Fatal error: Uncaught Error: Undefined variable，整个脚本中断 - 输入含中文引号、BOM 头、不可见控制字符 →
ParseError: syntax error, unexpected end of file
替代 eval 的三种真实可用方案
根据使用场景选，没有“通用安全版 eval”：
立即学习“PHP免费学习笔记（深入）”；
-
动态变量名访问：用
${$var_name}或$array[$key]替代eval("\$$var_name") -
配置表达式计算：用
symfony/expression-language或轻量级evalmath类库，白名单函数 + AST 解析，不执行任意 PHP -
模板逻辑：换
Twig或Blade，它们编译成原生 PHP，变量作用域隔离，{{ user.name }}不会变成代码注入点
别碰 create_function（已废弃）、assert()（PHP 7.2+ 默认禁用表达式）、preg_replace('/.*/e')（已被移除）——这些和 eval 是同一类危险机制。
如果真有 legacy 代码绕不开 eval
仅限完全可控、无任何外部输入的硬编码字符串，且必须加运行前校验：
- 用
token_get_all()扫描字符串，确认只含T_CONSTANT_ENCAPSED_STRING、T_VARIABLE、运算符等白名单 token - 禁止出现
;、{、function、class、include、exec等关键词（正则不够，必须 token 级） - 在
eval前加if (ini_get('safe_mode')) { die(); }是无效的——safe_mode 早被删了
真正难的是：你永远没法 100% 确认输入是否“完全可控”。哪怕一个日志 ID 经过层层过滤，也可能在某个环节被拼进 eval 字符串里。这种边界模糊，就是 eval 最危险的地方。
