gin中间件需按序注册以确保鉴权、日志、恢复等逻辑正确执行：鉴权中间件必须前置并显式c.set("user", user)，下游用c.get("user")配合ok判断；日志中间件需重置body或包装responsewriter；反向代理需透传头并配置可信ip段。
中间件里怎么拿到用户身份信息做鉴权
Gin 的中间件默认拿不到 context 里塞的用户数据，因为鉴权逻辑常在前序中间件执行，后续中间件得从 c.Keys 或自定义字段读取。别直接依赖 c.Get("user") 返回非空——它不报错但可能为 nil，容易漏判。
- 鉴权中间件（如 JWT 解析）必须调用
c.Set("user", user)显式存入，且确保它排在日志、业务路由之前 - 下游中间件要用
user, ok := c.Get("user")判断存在性，ok为false就该返回401 - 别在鉴权中间件里用
c.Next()后再取user——如果前面没 set，这里永远是空，而且错误已发生 - JWT 过期检查必须在解析时做，不能只校验签名；否则攻击者可重放过期 token，
ParseWithClaims的Valid方法要主动调用
Gin 日志中间件为什么总打不出请求体或响应体
因为 Gin 默认不缓存请求体，c.Request.Body 是单次读取流，日志中间件一读就空了，后边控制器再读就是空；响应体更麻烦，http.ResponseWriter 被封装过，直接读会丢内容甚至 panic。
- 要记录请求体，得提前用
c.Request.Body = ioutil.NopCloser(bytes.NewBuffer(bodyBytes))把原始字节重置回去，但注意别对大文件这么做，内存爆炸 - 记录响应体必须用
ResponseWriter包装器（如自定义responseWriter结构体），拦截Write和WriteHeader，并在c.Next()后读取缓冲内容 - 别在日志中间件里调用
c.ShouldBindJSON——它会消费 Body，导致后续绑定失败，错误信息变成invalid character - 生产环境建议只记录状态码、路径、耗时、IP，体内容留到 debug 模式开启，用
gin.Mode() == gin.DebugMode控制
多个中间件顺序写错会导致鉴权失效或日志错乱
Gin 中间件执行顺序严格依赖注册顺序，router.Use(a, b, c) 表示 a→b→c→handler，但返回时是 handler→c→b→a。很多人以为鉴权放最后才“兜底”，结果它根本没机会运行。
- 鉴权中间件必须在日志中间件之前：否则日志会把未授权请求也记下来，还可能因
c.Get("user")空 panic - 日志中间件必须在 recover 中间件之后：不然 panic 时日志没刷出，你只能看到空白日志和 500
- 跨域中间件（
Cors()）建议放在最前，避免预检请求被鉴权拦住，报OPTIONS method not allowed - 用
router.Group("/api").Use(auth, logger)比全局Use更安全，避免管理后台接口也被强鉴权
为什么本地调试正常，上线后中间件不生效
常见原因是反向代理（Nginx / ALB）没透传关键头，比如 X-Real-IP、X-Forwarded-For，导致 c.ClientIP() 返回 127.0.0.1；或者 TLS 终止在网关，c.Request.TLS 为空，误判为非 HTTPS 请求。
立即学习“go语言免费学习笔记（深入）”；
- 在 Gin 启动时显式设置信任代理：
router.ForwardedByClientIP = true，并用router.SetTrustedProxies([]string{"10.0.0.0/8", "192.168.0.0/16"})声明可信段 - 检查 Nginx 配置是否含
proxy_set_header X-Forwarded-For $remote_addr;，缺了这句c.ClientIP()就不可信 - HTTPS 判断别只看
c.Request.TLS != nil，应结合c.Request.Header.Get("X-Forwarded-Proto") == "https" - 容器部署时注意
TRUSTED_PROXIES环境变量是否被正确注入，K8s ConfigMap 里少一个空格都会让SetTrustedProxies解析失败
中间件不是插件，它是请求生命周期里的硬链路。顺序、数据传递、代理透传，三处任一松动，整个链就断在你看不见的地方。
