责任链模式适合哪些应用场景？
简化版
责任链模式适合多个处理器按顺序处理同一请求，并且处理器可以放行、拦截或择一处理的场景。常见应用包括 Web 过滤器链、权限校验、参数校验、网关过滤、审批流、风控规则、日志处理、异常处理和消息消费前置处理。
详细版
适合使用责任链模式的场景通常具备这些特征：
- 一个请求可能被多个处理器处理；
- 处理器之间有明确顺序；
- 某些处理器可以决定是否继续向后传递；
- 处理步骤经常新增、删除或调整；
- 调用方不应该依赖具体处理器集合。
典型场景包括：
- Web 请求过滤器；
- API 网关过滤链；
- 登录、权限、限流、参数校验；
- 请假、报销、合同审批流；
- 风控规则链；
- 消息消费前的校验、幂等、反序列化；
- 日志、监控、链路追踪；
- 异常处理器链。
不适合的场景是：步骤固定且强依赖、流程需要严格编排、处理器之间共享大量隐式状态，或者只有一个稳定处理器。
完整版教学
一、Web 请求过滤器是最典型场景
Web 请求进入应用时，通常要经过一系列通用处理：
请求 -> 跨域处理 -> 日志记录 -> 鉴权 -> 限流 -> 参数校验 -> Controller这些处理有明显责任链特征：
- 每个节点只负责一个横切能力；
- 节点之间有顺序；
- 某些节点可以拦截请求；
- 新增节点不应该改 Controller。
这就是为什么 Servlet Filter、Spring Interceptor、网关过滤器都很适合用责任链思想实现。
二、审批流适合“命中处理后继续或结束”
审批流也是常见例子。
比如报销审批：
- 1000 元以内主管审批；
- 10000 元以内经理审批；
- 超过 10000 元总监审批。
请求沿着审批链向上传递，某个处理器根据金额和权限决定是否审批、驳回或继续上报。
这类场景通常强调“谁有权限处理”，更接近纯责任链。
三、风控规则链适合动态组合
风控系统经常包含多条规则：
- 黑名单规则；
- 频率规则；
- 地域异常规则；
- 设备异常规则；
- 金额阈值规则；
- 历史行为规则。
这些规则可能根据业务线、活动、用户等级动态组合。责任链可以把每条规则做成独立处理器，然后按配置编排。
比如：
登录风控链：设备规则 -> IP 规则 -> 频率规则
支付风控链：金额规则 -> 黑名单规则 -> 行为规则同一个规则处理器也可以复用到多条链里。
四、消息消费前置处理也适合责任链
消息队列消费者在执行业务前，常常需要做一批通用处理：
- 消息反序列化；
- 幂等校验；
- 签名校验；
- 业务参数校验；
- 重复消费判断；
- 监控埋点。
如果每个消费者都手写这些逻辑，会产生大量重复代码。责任链可以把这些前置处理做成统一链路。
当某个节点发现消息重复消费，可以直接短路，不再执行业务逻辑。
五、异常处理器链适合按类型匹配
异常处理也可以用责任链思想。
比如：
参数异常处理器 -> 权限异常处理器 -> 业务异常处理器 -> 系统异常处理器每个处理器判断自己是否能处理当前异常。能处理就返回对应错误响应，不能处理就传给下一个。
这种场景更接近“纯责任链”：通常一个异常最终由一个处理器负责转换成响应。
六、什么时候不适合使用责任链
如果处理步骤非常固定，而且每一步之间强依赖，责任链未必是最佳选择。
比如订单支付核心流程：
创建支付单 -> 冻结优惠券 -> 调用支付渠道 -> 更新订单状态 -> 发送事件这些步骤有强事务和补偿语义，用责任链可能会隐藏流程边界。此时更适合用明确的流程编排、事务脚本、状态机或 Saga。
另一个不适合的情况是处理器之间通过上下文互相传递大量临时字段。这样表面上解耦，实际上形成了隐式耦合。
七、判断是否适合的面试回答框架
可以从四个问题判断：
- 是否有多个候选处理器？
- 处理器是否有顺序？
- 是否需要某个节点决定继续或停止？
- 处理器集合是否经常变化？
如果这四个问题大多回答“是”，责任链通常比较适合。
八、按“可拆节点和可变顺序”判断适用性
风控请求有 8 条规则，按租户启用其中 5 条；责任链可在启动期组装 5 个节点，而不必改主流程。
request -> enabled rules[5/8] -> reject or continue -> result责任链是否正确，不能只看节点都被注册，还要看请求到底经过哪些节点、在哪里停止以及返回阶段如何展开。应把“继续、已处理、拒绝、系统失败”建成可区分的结果，并让日志能够还原一次请求的完整路径。
九、链路顺序、短路与可观测性
| 检查维度 | 应确认的内容 |
|---|---|
| 机制正确性 | 适合责任链的处理器应单一、顺序可解释，并能给出继续、停止或失败的明确结果。 |
| 适用边界 | 必须原子提交的核心步骤、复杂回退和跨天等待不适合隐藏在普通责任链中，应使用事务编排或工作流。 |
| 测试证据 | 用记录型处理器覆盖全通过、主动短路、业务拒绝、节点异常和链尾无人处理 |
| 工程代价 | 重点测量链长、各节点耗时、最坏路径延迟和短路率，并确认动态装配不会产生重复节点或排序漂移 |
易错点：适合责任链的处理器应单一、顺序可解释，并能给出继续、停止或失败的明确结果。
十、常见误区与追问
- 误区：只要业务包含多个步骤就适合责任链。 固定必做步骤更像模板或管道，复杂状态流程更像状态机，不能只看步骤数量。
- 误区：责任链一定会让每个处理器都执行。 纯链可能命中一个节点就结束，不纯链也可能因拒绝、异常或短路提前终止，必须由链契约定义。
- 追问：审批流何时还能用简单责任链？ 层级线性、规则稳定且命中负责人后结束时可以；存在会签、回退和并行节点时应升级模型。
- 追问：责任链如何避免请求到链尾无人处理？ 提供明确的默认处理器或链尾失败结果，并对未处理请求记录指标，不能静默成功。
- 追问：责任链上线后最少要记录哪些信息？ 至少记录链版本、节点顺序、逐节点耗时与决策、短路位置、异常和最终处理结果。
十一、加强记忆
责任链适合“多个处理器按顺序处理一个请求”的场景，尤其是过滤、校验、审批、风控、网关、异常处理和消息消费前置处理。判断标准是：有顺序、可插拔、可短路、调用方不想知道具体处理器。强编排、强事务、强状态流转的核心业务流程要谨慎使用。