责任链模式在Python中宜用函数或可调用对象构成轻量链，避免Java式抽象类继承；推荐list+for循环替代递归，确保流程可控、异常可捕获；上下文须用可变对象（如自定义类）封装；必须处理“无人处理”兜底逻辑。
责任链模式在Python里不是靠继承强制实现的
Python没有抽象类或接口的硬性约束，所以你不需要定义 Handler 抽象基类再层层继承。直接用函数或可调用对象（比如带 __call__ 的类实例）串成链更轻量，也更符合 Python 的“鸭子类型”习惯。
常见错误是照搬 Java 写法：搞一堆 AbstractHandler、ApproveHandler、RejectHandler 子类，结果每个类只重写一个 handle() 方法，反而让逻辑分散、调试困难。
推荐做法是把审批规则封装成独立函数或小型类，每个只关心“自己能不能处理 + 处理完要不要继续”。例如：
def manager_approve(request):
if request.amount <= 10000 and request.department == "tech":
request.status = "approved"
return True # 终止链
return False # 继续下一个
<p>def hr_review(request):
if request.status == "approved":
request.audit_log.append("HR reviewed")
return True
return False
用 list + for 循环比递归更可控
很多教程用递归调用 next_handler.handle() 实现链式传递，但在实际审批业务中容易出问题：比如某个环节抛异常没捕获，整条链就断了；或者忘记设终止条件，导致无限调用。
立即学习“Python免费学习笔记（深入）”；
用普通 list 存处理器，配合 for 循环逐个尝试，能清晰控制流程走向、插入日志、加超时或熔断逻辑：
- 每个处理器返回
True表示“已处理且不往下传”，返回False表示“不处理，交下一个” - 可以随时在循环中检查
request.status是否已终态（如"rejected"或"approved"），提前跳出 - 方便统一加异常捕获：
try...except ApprovalError as e:记录后跳过当前处理器
审批上下文必须是可变对象，不能传原始 dict 或 tuple
如果用 dict 当请求参数，像 process(request={"amount": 5000})，那每个处理器内部改 request["status"] = "pending" 是生效的；但若误传 tuple 或冻结的 namedtuple，就会静默失败——因为不可变对象赋值只是新建局部变量，链上后续处理器完全看不到变化。
建议统一用简单类封装上下文，字段可读可写，还能加校验：
class ApprovalRequest:
def __init__(self, amount, department, initiator):
self.amount = amount
self.department = department
self.initiator = initiator
self.status = "pending"
self.audit_log = []
这样 manager_approve(req) 里写 req.status = "approved"，后续处理器一定能读到最新值。
别忽略“无人处理”和“全部跳过”的兜底逻辑
真实业务里常有边缘情况：金额超 500 万没人敢批、跨部门调岗流程缺失 handler、测试环境没配审批人……这些不会报错，但会导致 request.status 停留在 "pending"，前端卡住、定时任务反复重试。
必须显式检查链执行完的状态：
- 循环结束后加判断：
if req.status == "pending": raise NoHandlerFoundError(f"No handler approved {req}") - 或者约定默认行为：最后加一个
default_reject()处理器，专抓漏网之鱼 - 日志里至少记录“共尝试 X 个处理器，X-1 返回 False，第 X 个返回 True”，方便排查为什么某次没走 HR 环节
责任链真正的难点不在怎么连，而在每个节点的边界是否清晰、退出条件是否明确、失败路径有没有被看见。
