go微服务中安全中间件必须用context.context透传认证状态，禁用全局变量；需按ip+路径组合限流，支持多密钥轮换验证，并确保auth中间件位于链首以防绕过。
Go微服务里加中间件做安全防护，不是“要不要”的问题，而是“怎么加才不漏、不卡、不拖垮性能”的问题。直接上结论：用标准 http.Handler 链式中间件 + context 透传 + 独立校验逻辑，比在每个 handler 里手写 if !isValidToken(r) 更可靠；但若把所有规则塞进一个中间件里硬编码，后期维护会迅速失控。
HTTP中间件中如何安全传递认证状态
认证结果不能靠全局变量或闭包捕获，必须走 context.Context。否则在并发请求下，A 用户的 token 可能被 B 请求误读。
- 用
context.WithValue(r.Context(), authKey, userInfo)注入解析后的用户信息，authKey必须是私有类型（比如type authKey string），避免和其它中间件 key 冲突 - 下游 handler 通过
userInfo := r.Context().Value(authKey)获取，记得判空和类型断言 - 不要在中间件里修改原始
*http.Request的 Header 或 Body 来“伪造”认证——这会破坏请求幂等性，且和某些框架（如 Gin 的c.MustGet()）行为不兼容
为什么 rate limit 中间件必须区分 client IP 和 API 路径
只按 IP 限流会误伤 NAT 后的真实用户；只按路径限流又无法防住单个恶意账号高频刷接口。真实场景需要组合维度。
- 推荐用
net/http原生中间件时，从r.RemoteAddr提取 IP，但注意反向代理后要读X-Forwarded-For头——必须白名单可信代理地址，否则可被伪造 - 路径粒度建议用
r.URL.Path而非r.RequestURI，前者已解码，后者含原始 query，易被构造绕过 - 高并发下别用内存 map 计数，改用
golang.org/x/time/rate.Limiter+ 每路径独立 limiter 实例，避免锁竞争
JWT 校验中间件常见崩溃点
崩溃往往不出现在解析阶段，而出现在验证失败后的错误处理上——尤其是 panic 没 recover，或者返回了 500 却没写 body。
-
jwt.Parse返回err时，先判断是否为jwt.ValidationError类型，再区分是 expired、malformed 还是 signature invalid，分别返回 401 或 400 - 别在中间件里调用
http.Error后还执行next.ServeHTTP——必须 return，否则会 panic：“http: multiple response.WriteHeader calls” - 密钥轮换时，旧 token 还在有效期内，中间件需支持多 key 验证：遍历 key 列表，任一成功即放行，全部失败才拒绝
中间件顺序错位导致的安全绕过
安全中间件必须在日志、指标、压缩等中间件之前执行。否则攻击请求可能已被记录或响应已压缩，但校验还没开始。
- 典型错误顺序：
logging → auth → rateLimit—— 日志中间件先记下非法请求，auth 才拦，但日志已落盘，审计线索污染 - 正确顺序应为：
auth → rateLimit → logging → metrics - 若用 Gin，
router.Use(authMiddleware, rateLimitMiddleware)是对的；但若某个路由单独加了router.GET("/admin", adminOnly, handler)，而adminOnly没包含基础 auth，则整个链路失效
最常被忽略的一点：中间件本身没有“生命周期管理”。比如 JWT key 从配置中心动态更新，你得自己实现 keyProvider 接口并定期刷新，而不是启动时读一次就硬编码进闭包——否则密钥泄露后无法热替换，只能重启服务。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
