Go责任链应使用func(w http.ResponseWriter, r *http.Request) bool签名，显式返回true/false控制中断；避免http.HandlerFunc直接循环调用；推荐切片存储处理器并for遍历，而非结构体嵌套；依赖通过闭包注入，请求数据用context传递，禁止用panic控制流程。
Go 里责任链不是“搭个链表再遍历”，而是用函数签名统一控制权移交点——关键在 next 是否被显式调用，以及中断信号是否可预测。
用 func(http.ResponseWriter, *http.Request) bool 而不是 http.Handler 做处理器
HTTP 场景下，http.HandlerFunc 本身不带“是否终结”的语义，容易导致权限校验后忘记 return，结果后续 handler 还继续执行（比如又写了一次响应体，触发 http: multiple response.WriteHeader calls panic）。
-
func(w http.ResponseWriter, r *http.Request) bool的返回值是明确的中断信号：true = 已处理完毕，链终止；false = 继续传给下一个 - 所有处理器共享同一份
http.ResponseWriter，所以不能靠“不调用 next”来隐式中断——必须显式 return true，否则可能重复写入或状态错乱 - 别把
http.HandlerFunc直接塞进切片循环里用，它没有中断能力，本质是“fire-and-forget”型包装器
链式注册用切片 + for 循环，不用结构体嵌套 next 指针
Go 没有方法链式语法糖，硬写 auth.SetNext(log).SetNext(db) 看似优雅，实则增加 nil 判空负担、调试困难、且无法动态插入/移除节点。
- 用
[]HandlerFunc存处理器，for _, h := range handlers显式顺序执行，逻辑直白、断点好打、热更新也方便（比如运行时替换某段切片） - 结构体链式（如
AuthHandler{next: &LogHandler{}}）适合固定深度、需复用中间状态的场景（如审批流），但 Web 中间件几乎不需要——每个请求都是独立生命周期 - 切片方式天然支持条件跳过：比如开发环境跳过 rate limit，只需
if env != "prod" { handlers = remove(handlers, rateLimitHandler) }
依赖注入靠闭包，不塞进结构体字段
真实项目里，每个处理器都要访问 DB、配置、日志器等。若把这些全塞进结构体，会导致初始化臃肿、测试难 mock、且违背 Go “小接口、轻组合”哲学。
立即学习“go语言免费学习笔记（深入）”；
- 用闭包捕获依赖：比如
AuthHandler(authService *AuthService) HandlerFunc，返回的函数内部直接用authService.Validate() - 避免全局变量或单例：比如
var logger *zap.Logger，会破坏 handler 的可移植性与并发安全性 - 若需传递请求级数据（如用户 ID、trace ID），优先用
r = r.WithContext(context.WithValue(r.Context(), key, value))，而不是往结构体里加字段
别在链里用 panic 控制流程
有些实现用 recover() 捕获 panic 来跳出链，这会让错误路径不可见、堆栈丢失、且和 http.Server 默认的 panic 处理机制冲突（比如触发 500 页面但没日志）。
- 中断就用返回值：true/false 或 error，这是 Go 最自然的控制流表达
- 真正该 panic 的只有一种情况：程序员误传了 nil handler 到链中——那应该在
Chain()构造时就 panic，而不是运行时靠 recover 补救 - 如果某个环节必须 abort 并返回特定错误码（如 429），直接
http.Error(w, "...", http.StatusTooManyRequests)+return true
最常被忽略的一点：所有处理器共用同一个 *http.Request，但它的 Body 是单次读取流。如果你在 auth handler 里读了 body，后面 validation handler 就读不到——要么用 r.Body = ioutil.NopCloser(bytes.NewBuffer(bodyBytes)) 复制，要么统一提前解析并注入 context。
