go中间件开发是web架构能力分水岭，根植于net/http的http.handler接口，必须严格遵循func(http.handler) http.handler签名，按洋葱模型链式执行，顺序决定逻辑成败，context.context是跨中间件安全传参唯一途径。
Go语言中间件开发不是“进阶选修”，而是Web架构能力的分水岭——绕过它，你写的只是带路由的HTTP服务；掌握它，才真正开始构建可维护、可观测、可扩展的服务骨架。
中间件是net/http标准库的自然延伸，不是框架专属
很多人误以为中间件只属于Gin、Echo这类框架，其实它根植于net/http的http.Handler接口设计。只要理解func(http.Handler) http.Handler这个签名，就能在纯标准库中写出中间件，无需任何依赖。
- 标准库中间件必须返回
http.Handler，不能直接返回http.HandlerFunc（除非显式转换） - 错误恢复中间件里用
recover()捕获panic后，必须调用http.Error()写响应，否则客户端会卡住 - 包装
ResponseWriter时要重写WriteHeader()和Write()，否则状态码、body长度统计会失效
中间件链顺序决定逻辑成败，洋葱模型不是比喻而是执行事实
中间件按注册顺序从外向内包裹，请求进、响应出——前置逻辑在next.ServeHTTP()前，后置逻辑在之后。顺序错一位，日志可能漏打、鉴权可能被绕过、CORS头可能被覆盖。
-
loggingMiddleware放最外层才能统计全链路耗时 -
authMiddleware必须在业务处理器之前，且要在next.ServeHTTP()前检查并提前return，否则认证失败仍会进入业务逻辑 -
corsMiddleware通常放靠近业务层的位置，避免被内层中间件覆盖响应头
context.Context是中间件间传参的唯一安全通道
多个中间件之间传递数据（比如解析后的JWT claims、请求ID、用户ID），只能靠r.WithContext()注入context.Context。用全局变量或结构体字段共享状态，在高并发下必然出错。
- 不要用
map[string]interface{}存中间件数据——类型不安全、无生命周期管理 - 推荐用
context.WithValue(ctx, key, value)，key建议定义为私有类型（如type userIDKey struct{}），避免key冲突 - 下游中间件或handler通过
ctx.Value(key)取值，记得做类型断言和nil判断
真正难的不是写单个中间件，而是让它们协同工作时不互相干扰——比如日志中间件依赖的响应状态码，可能被错误恢复中间件改写；traceID注入可能被跨域中间件丢弃。这些细节没有文档会明说，只有在线上问题复盘时才会暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
