eval()是PHP中唯一原生动态执行字符串代码的方式，但极其危险，仅适用于受控场景；应优先使用表达式解析器等安全替代方案。
PHP中用eval()执行字符串里的代码，但必须谨慎
直接在字符串里动态执行PHP代码，唯一原生方式是eval()。它把传入的字符串当作PHP代码解析执行，不经过编译缓存，也没有作用域隔离——变量直接从当前作用域读写，执行完也不自动清理。这不是“高级技巧”，而是高危操作，仅适用于极少数受控场景（如配置驱动的简单表达式计算、模板引擎内部实现）。
常见错误现象：eval(): Syntax error, unexpected '}'（语法错）、Undefined variable（变量未定义却在字符串里引用）、执行后意外修改了外层变量。
- 字符串末尾必须有分号，
eval('return 42')会报错，得写成eval('return 42;') - 不能省略
return就指望拿到返回值：没return语句时eval()返回NULL - 所有变量都来自当前作用域——想传参进去？只能靠提前赋值，比如先设
$a = 5;，再eval('echo $a * 2;')
替代eval()的安全方案：用create_function()已废弃，改用匿名函数+extract()
create_function()在PHP 7.2+已被移除，别再用。如果确实需要“参数化执行字符串逻辑”，更可控的做法是：把字符串转为表达式，再用匿名函数封装，配合extract()注入变量（注意只用于可信数据）。
例如处理一个简单数学表达式"$x + $y * 2"：
立即学习“PHP免费学习笔记（深入）”；
function safe_eval_expr($expr, $vars) {
extract($vars); // $x=3, $y=4 → 注入到当前作用域
return eval("return ($expr);"); // 注意括号包裹，避免语法歧义
}
echo safe_eval_expr('$x + $y * 2', ['x' => 3, 'y' => 4]); // 输出 11这个模式把变量注入和执行分离，比裸eval()稍好控制，但仍依赖eval()本身。真正安全的路是避开动态PHP，改用专用表达式解析器（如symfony/expression-language）。
为什么assert()不是eval()的替代品
有人试过用assert($string)来执行字符串代码，这是严重误解。assert()在PHP 7+默认只做布尔断言，传字符串会触发Deprecated警告；开启zend.assertions=1且assert.exception=0时，它才可能执行，但行为不可靠、无返回值、无法捕获异常，且PHP 8.4起已明确标记为“将移除”。
-
assert('phpinfo()')在现代PHP中大概率静默失败或报错 - 它不返回表达式结果，不能用于计算
- 与
eval()相比，调试难度更高，错误信息更模糊
真正该考虑的：是不是根本不需要动态执行PHP
95% 声称“需要动态执行PHP”的场景，实际只需要解析结构化输入。比如用户输入"price > 100 && category == 'book'"，应该用表达式语言库，而不是拼接PHP字符串；比如模板渲染，应使用Twig或Blade这类预编译引擎，而非eval()渲染片段。
一旦字符串来源含用户输入、数据库内容或文件读取，eval()就等于给攻击者送shell。哪怕加了strip_tags()或正则过滤，也无法穷举PHP语法绕过方式。
复杂点在于：很多人卡在“怎么让配置项活起来”这一步，却没意识到，把逻辑从字符串里解耦出来，用数组+回调映射，往往更清晰、可测、可维护。
