当处理逻辑具有不确定、可变、可插拔的判断顺序，且各步骤仅关注自身是否能处理时，应选用责任链模式；它支持运行时动态组装与单点失效隔离，适用于HTTP中间件、日志过滤、权限校验等场景，而非严格顺序必执行流程。
什么时候该用 Chain of Responsibility 而不是 if-else 或 switch
当处理逻辑存在「不确定的、可变的、可插拔的」判断顺序，且每个步骤只关心自己能否处理、不关心后续时，责任链比硬编码分支更合适。比如：HTTP 中间件、日志分级过滤、权限校验多级兜底（先查缓存 → 再查 DB → 最后调远程服务）。
常见误用是把所有条件塞进一个链里却固定了顺序，结果比 if-else 更难调试——责任链的价值不在“链起来”，而在「运行时动态组装」和「单点失效不影响全局」。
- 适合：请求预处理（如鉴权、限流、埋点）、错误降级策略、消息路由分发
- 不适合：必须严格按 A→B→C 执行且每步都必走的流程（那是模板方法，不是责任链）
- 警惕：链过长 + 每个
Handle都做耗时操作 → 延迟叠加，不如提前聚合判断
Handler 接口怎么设计才不容易崩
Go 里典型写法是定义 type Handler interface { Handle(ctx context.Context, req interface{}) (resp interface{}, err error) }，但实际踩坑点多在返回控制上：
- 不要强制要求每个
Handle必须调next.Handle()—— 否则无法短路（如鉴权失败直接 return） - 推荐让
Handle返回bool表示“是否已处理完毕”，由调用方决定是否继续：if h.canHandle(req) { return h.process(req), true } return nil, false - 避免在
Handler内部 panic；统一用error传递异常，否则链中断后 recover 不到 - Context 一定要透传，别在中间层新建
context.Background()，超时和取消会失效
如何动态插入/跳过某个 Middleware 而不改主逻辑
标准 Go HTTP 中间件本身就是责任链，但默认是编译期固定顺序。要支持运行时调整，关键在链的构建方式：
立即学习“go语言免费学习笔记（深入）”；
- 用切片存
[]func(http.Handler) http.Handler，启动时按配置顺序 append，再用chi或自建Chain类型组合 - 给每个中间件加
Enabled() bool方法，在链执行前过滤：for _, m := range chain { if !m.Enabled() { continue } h = m(h) } - 测试时可临时用
func(http.Handler) http.Handler匿名包装替换某环，比如 mock 数据库访问环节 - 注意：热更新链结构需加锁，尤其并发 reload 配置时，建议用
atomic.Value存当前链快照
为什么你的 Chain 在压测时 CPU 翻倍
不是链本身慢，而是常见实现引入了隐式内存分配或锁竞争：
- 每次调
next.Handle()都 new 一个新context.WithValue？键值对堆分配 + GC 压力飙升 → 改用context.WithDeadline等轻量上下文，或复用sync.Pool缓存上下文键 - 链中用了
log.Printf或fmt.Sprintf拼接日志？字符串逃逸到堆，高频请求下显著拖慢 → 改用zap.Stringer或预分配缓冲区 - 多个 goroutine 同时往同一个链切片 append？没加锁就 panic；用
append本身不是原子操作 → 动态链变更必须串行化，或改用读多写少的RWMutex - 最隐蔽的：链节点里调了
time.Sleep或阻塞 IO → 整条链卡住，表现像 CPU 高（其实是 goroutine 积压）
责任链真正的复杂点从来不在结构，而在各环节对资源（context、error、goroutine、内存）的边界意识 —— 少一个 ctx.Done() 检查，整条链就可能变成泄漏源。
