Go中责任链模式核心是函数类型HandlerFunc与Chain结构体组合，每个处理器显式调用next控制流程；中间件应职责单一、顺序敏感；禁用defer/panic实现回溯；需注意逃逸、内存分配与调用开销。
责任链模式在 Go 中的核心实现方式
Go 没有类继承，也不支持接口的默认方法，所以不能照搬 Java 那套 Handler 抽象类 + setNext() 的写法。真正的 Go 式责任链，靠的是函数组合与接口嵌入，核心是让每个处理器持有下一个处理器的引用，并决定是否继续传递。
最常用且符合 Go 习惯的做法是定义一个函数类型作为处理器：
type HandlerFunc func(ctx context.Context, req interface{}) (resp interface{}, err error)
再用结构体包装它，支持链式拼接：
type Chain struct {
handlers []HandlerFunc
}
关键点在于：每个 HandlerFunc 必须显式调用 next(ctx, req) 才能往下走——不调，链就断了。这不是框架自动做的，是开发者控制的。
立即学习“go语言免费学习笔记（深入）”；
如何构建可复用的责任链中间件（如日志、鉴权、限流）
真实项目里，责任链常用于 HTTP 中间件或 RPC 拦截器。比如给 gRPC server 加一层统一处理逻辑，你得让每个 handler 能拿到 context.Context 和原始请求，返回修改后的请求或错误。
典型错误是把业务逻辑硬编码进 handler，导致无法复用。正确做法是把通用能力抽成独立函数：
-
LoggingHandler只负责打日志，不关心后续逻辑 -
AuthHandler只校验 token，校验失败直接 return，不调next -
RateLimitHandler用golang.org/x/time/rate控制频次，超限就中断链
拼装时用链式语法更清晰：
chain := NewChain().Use(LoggingHandler).Use(AuthHandler).Use(Handler)
注意：顺序很重要。AuthHandler 必须在业务 Handler 前，否则可能绕过鉴权。
为什么不能用 defer 或 panic 实现“自动回溯”
有人试图用 defer 在 handler 退出时执行清理，或者用 panic/recover 实现类似过滤器的“后置逻辑”，这是危险的。
原因很实际：
-
defer是栈式执行，但责任链是线性调用，上一个 handler 的defer不知道下游是否执行成功 -
panic会中断整个 goroutine，而责任链中部分 handler 失败本应可控（比如返回err != nil），没必要上升到崩溃级别 - HTTP handler 里 panic 会被
http.ServeMux捕获并返回 500，掩盖了本该由业务 handler 明确返回的 401/429 等语义化错误
真正需要“后置”的场景（比如统计耗时、释放资源），应该在 handler 内部手动 wrap，而不是依赖运行时机制。
性能与内存分配需要注意什么
每次调用 Chain.Serve() 时，如果 handler 切片是闭包捕获的，容易造成逃逸；如果 handler 本身要频繁创建临时对象（比如解析 JSON、构造 map），会影响 GC 压力。
优化方向很具体：
- 避免在 handler 内做
json.Unmarshal多次——上游统一解一次，透传结构体指针 - 不要在链中反复 new 同一个对象，考虑用
sync.Pool（比如日志字段 map） - 如果 handler 逻辑极轻量（如只做字段判空），直接内联比封装成函数调用更省开销
- 用
benchstat对比Chain.Use(a).Use(b).Serve()和手写a(ctx, req, func(){b(...)})的差异，有时链式语法的间接调用成本不可忽略
责任链不是银弹。当 handler 数量稳定且少于 3 个、逻辑耦合紧密时，硬编码调用反而更清晰、更快、更容易测试。
