Go中责任链需用结构体Next字段显式串联，类型为同构Handler接口；上下文用context.Context传递并确保key私有、ctx更新后传递；每层Serve需defer recover()捕获panic；避免直接使用net/http.Handler拼链。
Go 里怎么用 Next 字段串起 Handler 链
责任链在 Go 里没有语言级支持，靠结构体字段显式串联是最稳的写法。别想用接口方法自动跳转，Go 接口不存状态，Next 必须是字段，否则链一断就找不到下家。
常见错误是把 Next 放进接口定义里，结果每个实现都得自己管跳转逻辑，反而让调用方重复写 if h.Next != nil { h.Next.Serve(req) } —— 这违背了责任链“统一入口、隐式传递”的本意。
-
Next字段类型必须是同构 handler 接口，比如type Handler interface { Serve(*Request) error } - 构造链时用链式赋值最清晰：
h1.Next = h2; h2.Next = h3，别用嵌套函数返回新 handler，那会丢失引用 - 空
Next不代表终止，而是“无后续处理”，业务逻辑该返回响应还得返回，别默认透传
中间件式责任链里如何安全传递上下文数据
Go 的 context.Context 是唯一被广泛接受的跨 handler 传参方式。别用全局变量、闭包捕获或自定义 map，前者线程不安全，后者破坏 handler 可复用性。
典型坑是 handler 修改了 ctx 却没往下传：ctx = context.WithValue(ctx, key, val) 后忘了传给 next.Serve()，下游永远拿不到。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有 handler 的
Serve方法签名必须接收context.Context，而不是只在首层注入 - 用
context.WithValue前确认 key 是私有类型（如type userIDKey struct{}），避免 key 冲突 - 如果要改请求体（如解密、重写 path），别直接改原始
*http.Request，而是用req.Clone(ctx)创建新实例再传下去
HTTP 中间件链遇到 panic 怎么不崩整个服务
Go 的 panic 默认向上冒泡，一个 handler panic 会让整个 HTTP 连接中断。责任链里必须每层都 recover，且只 recover 自己这一环的 panic —— 别试图在顶层统一捕获，那样会掩盖哪一环出的问题。
错误现象：加了 defer recover() 但日志没打出来，因为 panic 发生在 goroutine 里（比如异步校验），主链早执行完了。
- 每个 handler 的
Serve函数开头加defer func() { if r := recover(); r != nil { log.Printf("handler panic: %v", r) } }() - 如果 handler 内启了 goroutine，那个 goroutine 里也得单独加
defer recover() - recover 后别吞掉错误，至少记录
panic的堆栈（用debug.PrintStack()），否则查问题像盲人摸象
为什么不用 net/http.Handler 接口直接拼链
因为 http.Handler 只有一个 ServeHTTP(http.ResponseWriter, *http.Request) 方法，没法表达“我处理完，要不要继续往下走”。硬塞会导致每个中间件都要手动判断是否调用 next.ServeHTTP()，和责任链“可中断、可跳过”的语义冲突。
更麻烦的是 http.ResponseWriter 是一次性写的，一旦某层写了 header 或 body，下游再写就会 panic：http: multiple response.WriteHeader calls。
- 真要用标准库接口，得包装一层：定义自己的
ChainHandler结构，内部持有http.Handler和Next字段，由它统一控制流转 - 别在 handler 里直接调用
next.ServeHTTP()，而应通过ChainHandler的Next.Serve()统一入口，这样才方便加日志、超时、熔断等横切逻辑 - 如果项目已重度依赖
http.Handler，优先考虑用alice或negroni这类成熟链式中间件库，它们已经处理了 writer 包装、panic 捕获等细节
链的断裂点往往不在首尾，而在中间某个 handler 忘记设 Next 或提前 return；上下文传参最容易错的是 key 类型重复或 ctx 未更新就传给下家；HTTP 场景下最隐蔽的坑是 response writer 被多次写入——这些地方不打日志、不写测试，线上出问题只能翻代码猜。
