expressionlanguage可实现动态规则引擎，但需手动处理变量注入、错误兜底、缓存及上下文隔离；变量须显式传入且键名严格匹配，嵌套对象可点取，禁止传入资源/闭包，建议浅层类型校验。
直接结论：用 ExpressionLanguage 实现动态业务规则引擎是可行的，但必须手动封装变量注入、错误兜底、缓存和上下文隔离——它本身不提供“规则管理界面”或“版本回滚”，只负责安全求值。
怎么传入运行时数据并避免变量污染
表达式里写的 user.age >= 18 中的 user 不是全局变量，必须显式通过第二个参数数组传入。漏传或键名不一致会导致 Variable "user" is not defined 错误。
- 变量名必须完全匹配：传
['currentUser' => $user]，表达式就得写currentUser.age，不能混用user - 嵌套对象可直接点取：只要属性 public 或有 getter（如
user.profile.city），无需提前 flatten - 禁止传入原始资源句柄（如 PDO 实例）、闭包、未序列化的对象——会触发
Serialization of 'Closure' is not allowed - 建议对传入数据做浅层类型校验（比如
is_array($user) && isset($user['age'])），否则表达式报错信息不直观
为什么 compile() 比 evaluate() 更适合高频规则
compile('order.total > 500') 返回的是 PHP 代码字符串，比如 ($order['total'] > 500)，你可以 eval() 它（不推荐）或用 create_function() 包装后缓存复用。而 evaluate() 每次都走完整解析 → AST → 执行流程，开销大。
- 编译后结果依赖变量名列表：必须明确声明
['order']，否则生成的代码无法绑定上下文 - 编译不等于执行：
compile()不检查变量值是否存在，只校验语法；真正出错要等到执行时 - 线上环境建议预编译：把规则字符串在部署时转成 PHP 函数存到
var/cache/，跳过 runtime 编译 - 注意 PHP 版本兼容：
create_function()在 PHP 8.0+ 已废弃，改用eval("return function (\$order) { return {$compiled}; };")
自定义函数注册的实际限制
注册 date_diff_in_days() 这类函数看似灵活，但要注意：编译模式下只使用编译器回调（第一个闭包），而解释模式用执行回调（第二个闭包）。两者逻辑不一致就会出错。
- 两个回调必须语义等价：比如编译版返回
"date_diff(...)"字符串，执行版就得真调date_diff() - 不能注册带副作用的函数：比如
send_email()—— 编译时不会执行，但用户可能误以为“写了就发” - 函数名不能和内置冲突：
count、in、keys等已存在，覆盖会导致行为异常 - 参数数量固定：不支持
...$args，多参需显式声明function ($a, $b, $c)
容易被忽略的沙箱边界和安全盲区
ExpressionLanguage 不是通用 PHP 沙箱。它只限制语法层面（比如禁止 foreach、class 关键字），但不阻止你传入一个能任意读文件的对象。
- 如果传入的
$user对象有个getPasswordHash()方法，表达式user.getPasswordHash() == 'xxx'就能调用它 - 数组访问越界不会抛异常，而是返回
null，比如items[999].price→null，后续比较可能静默失败 -
lint()只检查语法，不校验变量是否真实可用，更不防逻辑漏洞（比如user.balance 允许透支） - 真正生产级规则引擎必须加一层：对表达式字符串做白名单扫描（禁用
file_get_contents、exec等敏感词），哪怕它根本调不到
