如何应用职责链模式实战处理复杂的业务审批流及变量状态的逐级传递

说到职责链模式处理审批流，很多人第一反应就是“把审批环节一个个串起来”——但这种理解其实把问题想简单了。真正的核心在于：不是流程去驱动节点，而是每个审批节点自己决定“我该不该管、管完了还用不用往下传”。这个思维转换，才是关键。

要实现这个目标，整个体系必须围绕一个统一的可变上下文来运转。这个上下文得承载审批状态和业务数据，并且允许所有节点读写。不能用原始数组传参，必须封装成可变对象，比如DTO类或者标准的stdClass实例。每个Handler都可以往里面写字段：像approved_by、approved_at、finance_sign、errors这些，后续节点才能基于前序结果做判断。

举个例子，初始上下文至少得包含业务主键（比如order_id）、核心参数（金额、部门、紧急程度），以及空状态字段（比如['passed' => true, 'errors' => []]）。FinanceHandler审批通过后，会主动写入$context['finance_sign'] = ['user_id' => 123, 'at' => time()]。而DirectorHandler的canHandle()方法则会检查isset($context['finance_sign']) && $context['amount'] > 5000，满足条件才介入。这样一来，整个流程的决策逻辑就由上下文状态驱动，而不是外部硬编码控制流程走向。

节点自主决策：是进是退，自己说了算

每个Handler不必强制调用next，而是根据当前上下文状态决定行为路径。返回值结构必须统一，推荐包含三个关键键：passed（整体是否通过）、next（是否继续流转）、errors（本节点产生的错误）。

比如ManagerHandler处理金额≤3000的单子，满足条件就设'passed' => true和'next' => false；不满足则直接返回['passed' => true, 'next' => true, 'errors' => []]，让链继续往下走。

驳回场景更直观。FinanceHandler检查到发片缺失，返回['passed' => false, 'next' => false, 'errors' => ['invoice_missing']]，链自然中断。这里必须有个兜底逻辑：如果所有canHandle()都返回false，或者所有handle()都没有设置passed，那么系统应该抛出UnhandledRequestException，避免静默失败这种坑爹情况。

动态组装链：插拔自如，加签不费劲

链的构建不能写死在Controller或Service初始化里，得从配置或缓存中读取Handler列表，按getOrder()排序后注入next引用。比如配置文件config/approval_chain.php返回['FinanceHandler', 'LegalHandler', 'DirectorHandler']，按顺序构建链。如果某次要临时关闭LegalHandler，只需从配置中移除类名，或者让它的canHandle()恒返回false——这比改代码优雅多了。

加签也无需新增节点。FinanceHandler内部检测到金额超过50000，可以主动调用(new LegalHandler())->handle($context)，然后合并errors，再决定是否继续传给DirectorHandler。整个过程对链结构完全透明。

驳回重提：跳过已审节点，靠状态驱动

重提时不再走完整链。每个节点自己查数据库或缓存，判断“上次是否已审且未变更关键字段”，从而决定是否跳过。比如ManagerHandler在handle()开头查Cache::get("approval:{$context['order_id']}:manager")，如果存在且status == 'approved'，就直接返回['passed' => true, 'next' => true]

如果申请人修改了金额，缓存中对应的key会被清空，该节点就会重新执行审批逻辑。所有跳过逻辑都集中在各Handler内部，既不污染链结构，也不增加Controller层的分支判断——这才是职责链模式的精髓所在。