最稳起点是net/http原生Handler链+context.Context；并发误用、上下文断裂、运行时不兼容是主要陷阱；需显式调用r.WithContext()传递ctx；goroutine必须监听ctx.Done()防泄漏。
Go 语言写高性能网络中间件，net/http 原生 Handler 链 + context.Context 是最稳的起点，不是非得套框架；真正掉坑的地方往往在并发模型误用、上下文传递断裂、或把中间件当黑盒硬塞进不兼容的运行时（比如 fasthttp）。
为什么别急着用 Negroni 或 Gin 中间件接口
Negroni 的 ServeHTTP(rw, r, next) 和 Gin 的 gin.HandlerFunc 看似统一，但底层假设不同：Negroni 仍基于标准 http.Handler，而 Gin 自己封装了 *gin.Context，它不是 context.Context 的简单包装——字段生命周期、取消信号、值存储方式都经过定制。混用会导致：
-
ctx.Value()在 Gin 中间件里取不到你在前一层http.Handler里塞的值，因为*gin.Context没桥接原生context.Context的全部语义 - 用
negroni.WithRecovery()包裹 Gin 路由时，panic 可能被吞两次，日志重复且堆栈错乱 - fasthttp 的中间件完全不兼容
net/http接口，强行移植会重写所有Request/ResponseWriter交互逻辑
context.Context 必须在每层中间件中显式传递
很多人以为 r.Context() 天然贯穿整条链，其实不然：一旦中间件自己调用 next.ServeHTTP(w, r) 却没更新 r，后续中间件拿到的就是原始请求对象，WithValue 写入的内容就丢了。典型错误写法：
func BadAuth(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx := context.WithValue(r.Context(), "user_id", 123)
// ❌ 错：没把新 ctx 绑回 *http.Request
next.ServeHTTP(w, r) // 这里 r.Context() 还是旧的
})
}正确做法必须用 r.WithContext(ctx)：
立即学习“go语言免费学习笔记（深入）”；
func GoodAuth(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx := context.WithValue(r.Context(), "user_id", 123)
next.ServeHTTP(w, r.WithContext(ctx)) // ✅
})
}更安全的方式是封装一个工具函数，避免每次手写 WithContext。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
goroutine 泄漏比性能差更致命
中间件里起 goroutine 很常见（比如异步打日志、上报指标），但若没控制生命周期，极易泄漏：
- 用
go func() { ... }()启动协程，却不监听ctx.Done()，该协程会在请求结束后继续跑，持有 request、response、buffer 等资源 - 用
time.AfterFunc延迟清理，但没绑定到请求上下文，超时后无法取消 - channel 不带缓冲且无 select default 分支，写入阻塞导致 goroutine 永久挂起
推荐模式：所有后台任务必须接收 context.Context 并在 select 中监听 ctx.Done()，例如：
func AsyncLog(ctx context.Context, msg string) {
go func() {
select {
case <-time.After(100 * time.Millisecond):
log.Println(msg)
case <-ctx.Done():
return // 请求已结束，放弃日志
}
}()
}中间件顺序决定行为边界，不是可随意调换的插件
比如 CORS、Recovery、Logging 三者顺序错了，结果可能完全不同：
-
CORS放最外层：预检请求（OPTIONS）能被正确响应；放里层则可能被Recovery拦截或被鉴权拒绝，导致前端收不到允许头 -
Recovery必须包裹业务 handler，但不能包裹CORS——否则 panic 时不会返回Access-Control-Allow-Origin，浏览器直接报 CORS error 而非 500 -
Logging放最外层才能统计所有请求；若放在Auth后，则未认证请求不会被记录，监控盲区变大
没有“通用最佳顺序”，只有“符合你协议语义的顺序”。真实线上网关常按：CORS → RateLimit → Auth → Logging → Recovery → Business 层叠，每一层只做一件事，且明确知道上层是否已处理过错误或跨域。
真正难的不是写出一个中间件，而是让它在 10 万 QPS 下不泄漏 goroutine、不丢上下文、不因顺序错乱导致安全绕过——这些细节藏在每行 r.WithContext() 和每个 select 的 ctx.Done() 分支里。
