rulerz 不适合 laravel 新项目，别装。它已停止维护（last commit 2021），php 8.2+ 和 laravel 11 兼容性差，运行时大概率报 typeerror 或 parseerror，且不支持 laravel 的自动服务发现与配置发布机制。
直接说结论：RulerZ 不适合 Laravel 新项目，别装。 它已停止维护（last commit 2021），PHP 8.2+ 和 Laravel 11 兼容性差，运行时大概率报 TypeError 或 ParseError，且不支持 Laravel 的自动服务发现与配置发布机制。
为什么 RulerZ 在 Laravel 里跑不起来
RulerZ 依赖旧版 hoa/compiler 和 hoa/ruler，这两者早在 2022 年就彻底归档，不再接收 PHP 8.2+ 的语法修复。Laravel 11 默认要求 PHP ≥ 8.2，一执行 composer require knplabs/rulerz 就会触发版本冲突或静默跳过安装——composer require 成功但 vendor/knplabs/ 下空目录、autoload 无注册、php artisan tinker 里 new RulerZ\RuleBuilder() 直接抛 Class not found。
常见错误现象：
- 运行
composer require knplabs/rulerz后，composer.json写入了依赖，但vendor/里没生成对应文件夹 - 手动
composer dump-autoload也无效，因为它的composer.json中"autoload"段未适配 PSR-4 标准路径 - 强行用
require_once加载类，又因hoa/compiler使用已被废弃的token_get_all()行为导致解析失败
替代方案：用 Laravel 原生能力 + 简单封装
90% 的“规则引擎”需求，其实只是条件组合判断（如：用户等级 ≥ 3 且订单金额 > 500 且非黑名单），根本不需要引入外部 DSL 解析器。Laravel 自带的 Illuminate\Support\Optional、集合高阶消息、以及闭包策略就足够。
实操建议：
- 把规则写成独立 PHP 类，实现统一接口：
interface Rule { public function passes($data): bool; } - 用 Laravel 的
Container自动解析依赖（比如注入UserRepository查询状态） - 组合多个规则时，用集合操作：
collect([$rule1, $rule2])->every(fn($r) => $r->passes($input)) - 需要动态表达式？用
eval()是危险的，改用symfony/expression-language（Laravel 10+ 已内置支持）
示例：symfony/expression-language 替代 RulerZ 的核心逻辑：
$language = app('expression.language');
$result = $language->evaluate('user.level >= 3 and order.total > 500', [
'user' => $user,
'order' => $order,
]);
真要 DSL 引擎？选活跃维护的替代品
如果业务强依赖 YAML/JSON 规则文件 + 运行时加载（例如风控、营销活动配置），优先考虑仍在维护的库：
-
spatie/laravel-rules：专注验证规则扩展，与 Laravel 验证器无缝集成，支持自定义规则类和闭包 -
laravel-eloquent-query-builder：用数组结构描述查询条件，可转为 Eloquent Query，适合前端传参驱动后端逻辑 - 自己封装一个轻量
RuleEvaluator：基于array_reduce+ 策略模式，50 行内搞定，可控、可测、无外部依赖
注意：composer require spatie/laravel-rules 装完后必须运行 php artisan vendor:publish --provider="Spatie\LaravelRules\RulesServiceProvider"，否则配置不生效——这是它和 RulerZ 最关键的区别：前者是 Laravel First，后者是框架无关却已掉队。
真正容易被忽略的点：规则引擎的复杂度不在“怎么写语法”，而在“怎么热更新”“怎么灰度”“怎么审计执行日志”。RulerZ 连基础的执行上下文追踪都没有，上线后出问题连哪条规则命中的都查不到。
