eval() 动态创建类极危险，因直接执行字符串代码，输入可控即导致远程代码执行（RCE），如 URL 参数注入可写入 WebShell；PHP 8.1+ 加警告但不阻止，OPcache 缓存难清除，静态分析失效。
用 eval() 动态创建类为什么危险
因为 eval() 会把字符串当作 PHP 代码直接执行，只要输入里混进恶意代码（比如用户提交的字段、日志内容、配置文件片段），就等于给攻击者开了个 shell。不是“可能被利用”，而是“只要能控制输入，就能 RCE”。真实案例里，有人用 eval('class '.$name.'{}') 做插件热加载，结果变量 $name 来自 URL 参数，直接导致服务器被写入 WebShell。
- PHP 8.1+ 已对
eval()加了更严格的警告，但不阻止执行 - OPcache 会缓存
eval()生成的代码，出问题后重启也清不掉 - 静态分析工具（如 PHPStan、Psalm）基本无法检查
eval()内部逻辑，等于主动放弃类型安全
替代 eval() 创建类的三种可行方式
核心思路是：把“动态”从代码执行层移到类定义或对象实例化层。真正需要的往往不是“运行时造一个新类名”，而是“按需拿到某个类的实例”或“复用结构但换行为”。
- 用工厂函数 + 已定义类：提前写好
class HandlerA、class HandlerB，再用match($type) { 'a' => new HandlerA(), 'b' => new HandlerB() }分发 - 用匿名类（PHP 7.0+）：适合一次性的、结构简单且不需复用的场景，例如
new class($config) implements Processor { ... } - 用反射 + 标准类：如果必须动态组合属性/方法，优先考虑
stdClass或数组，配合__call()/__get()拦截，而不是硬造类
class_exists() 和 require_once() 能否安全替代 eval()
不能直接替代“动态创建”，但能解决 90% 的实际需求——多数所谓“动态类”，本质是“根据字符串加载已有类”。这时候重点不是造类，而是找类。
-
class_exists($name)必须配合自动加载（autoload或Composer），否则返回false不代表类不存在，只代表没加载过 - 手动
require_once 'path/to/' . $name . '.php'风险低，但路径拼接必须严格过滤：preg_match('/^[a-zA-Z0-9_]+$/', $name)，禁止点号、斜杠、空格 - 注意命名空间：如果类在
App\Handlers下，$name = 'EmailHandler'，实际要加载的是App\Handlers\EmailHandler，别漏掉前缀
真要动态生成类结构？用 ProxyManager 或 nikic/php-parser
极少数场景确实需要运行时生成完整类（比如 ORM 的实体代理、AOP 切面），这时应交给专业库处理，而不是手写 eval() 字符串拼接。
立即学习“PHP免费学习笔记（深入）”；
-
ProxyManager（推荐）：通过ClassGenerator或LazyLoadingValueHolderGenerator生成代理类，输出的是合法 PHP 文件，可缓存、可调试、可静态分析 -
nikic/php-parser：适合需要解析/修改 AST 的场景，比如从 JSON Schema 生成 DTO 类，但开发成本高，仅限框架级需求 - 自己写代码生成器？可以，但生成的 PHP 文件必须写入磁盘并用
include加载，绝不要eval(file_get_contents(...))—— 后者和直接eval()几乎等价
最常被忽略的一点：动态类生成通常伴随着动态方法调用（call_user_func_array()、__call()），这些地方的参数校验比类本身更易出漏洞。别光盯着“怎么造类”，先想清楚“谁来调、传什么、怎么验”。
