composer不是规则引擎，而是通过插件机制、事件钩子和包隔离能力支持规则引擎构建；需自行设计契约、注册与热加载机制，依赖psr-4类、接口注入及外部配置实现真正可插拔。
Composer 本身不是规则引擎，也不提供规则执行能力；它只是依赖管理工具。所谓“基于 Composer 构建规则引擎”，本质是利用 Composer 的插件机制、事件钩子和包隔离能力，把规则定义、加载、校验、热替换等逻辑拆解为独立包，并通过 Composer 统一调度生命周期。这和 Lean 里用 Composer 实现策略热插拔的思路一致，但不是开箱即用的功能——得自己搭骨架。
为什么不能直接用 composer require rule-engine/core？
因为没有这样的通用包。市面上所有“规则引擎”PHP 包（如 php-rules、symfony/expression-language）都只解决表达式解析或条件判断，不解决规则的发现、激活、版本共存、上下文注入这些工程问题。Composer 能帮上忙的点，在于它天然支持：
- 按命名空间自动加载规则类（只要包含
autoload配置） - 通过
composer install触发post-install-cmd事件，可生成规则注册表缓存 - 用
conflict字段阻止不兼容的规则包共存（比如两个包都试图注册同名RuleType） - 靠
replace字段让自研规则包替代上游包（例如用内部风控规则包替换开源的payment-validator）
怎么让规则包真正“可插拔”？
关键不是写个 rules/ 目录，而是让每个规则包声明自己的“契约”并被主程序识别。典型做法是：
- 每个规则包在
composer.json中定义extra.rule-type，比如"extra": {"rule-type": "fraud-detection"} - 主程序监听
PackageEvents::POST_INSTALL，扫描所有已安装包的extra，构建规则类型索引 - 运行时通过
RuleFactory::create('fraud-detection')拿到对应包提供的实现，而不是硬编码new FraudRule() - 避免在规则包里写
require_once或全局函数——所有入口必须是 PSR-4 类，且构造器只接受接口（如RuleContextInterface）
否则一旦某个规则包升级，就可能因依赖变更导致整个规则链崩掉——这不是 Composer 的错，是你没约束好契约边界。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer.lock 文件动不得，但规则配置要动态生效
composer.lock 锁的是包版本，不是规则行为。规则参数（如阈值、白名单、开关状态）必须外置：存在数据库、Redis 或 YAML 文件里，由主程序在运行时读取并传给规则实例。常见错误是把规则开关写进 config/rules.php 然后 require 进来——这会导致改配置必须重跑 composer dump-autoload，违背“热插拔”本意。
真正轻量的热生效方式是：
- 规则包提供
RuleConfigProviderInterface，主程序统一调用->getConfig()获取当前配置 - 配置变更后发送信号（如
kill -USR2）触发主进程 reload config 缓存，不重启服务 - 禁止规则包在
activate()插件方法里做耗时操作（如连接 DB），只做元数据注册
最易被忽略的一点：规则包之间的依赖冲突不会报错，直到运行时才 Class not found 或 Method not implemented。因为 Composer 解析阶段只看 require，不校验接口实现。所以必须在 CI 阶段加一步 phpstan analyse --level=7 src/ 扫描规则契约一致性，而不是等上线才发现 FraudRule 少实现了 getPriority() 方法。
