应先用c.getheader("authorization")获取头，再trim空格、按空格切分并校验长度≥2且首段为"bearer"（大小写不敏感），最后清理控制字符；jwt解析须显式校验exp等字段，透传用户id需用c.get+类型断言而非mustget。
怎么从 Authorization 头里安全取 token
直接用 c.GetHeader("Authorization") 拿值，但别跳过格式校验——常见错误是没 trim 空格或硬写 strings.Split(header, " ") 导致下标越界 panic。
正确做法是先 strings.TrimSpace()，再按空格切分，且必须检查切片长度 ≥ 2；还要确认前缀是 authorizationTypeBearer（小写），不是 Bearer 或 BearER。
- 忽略大小写比较建议用
strings.EqualFold(tokenParts[0], "bearer") - token 字符串本身不能含控制字符，建议用
strings.TrimRight(tokenParts[1], "\x00-\x1f\x7f")清理 - 开发时可加
log.Printf("raw auth header: %q", header)，上线前删掉或走结构化日志
jwt.Parse 为什么校验通过了但 token 还是无效
github.com/golang-jwt/jwt/v5 的 Parse 默认不校验 exp、nbf 等时间字段，只做签名验证。所以即使 err == nil，token.Valid 仍可能是 false。
必须显式传入校验器，比如：jwt.WithValidator(jwt.ExpectedClaims{TimeFunc: time.Now})，或者手动调 token.Claims.(jwt.MapClaims).VerifyExpiresAt(time.Now(), true)。
- 别只判
err != nil就返回错误——要同时检查token != nil && token.Valid == false - 过期时间误差建议留 1~2 秒容错，避免因服务器时钟微偏导致误拒
- 如果用了自定义
Claims结构体，记得实现Valid() error方法
用户 ID 怎么透传给 handler 才不会 panic
中间件里用 c.Set("user_id", userID) 存值没问题，但 handler 里取值时，c.MustGet("user_id") 是危险操作——它在 key 不存在时直接 panic，不该用于鉴权后逻辑。
安全写法是两步：先 v, ok := c.Get("user_id") 判断是否存在，再 uid, ok := v.(uint64) 做类型断言。如果类型不对，ok 为 false，可统一返回 400 或记录告警。
- 键名统一用小写+下划线，如
"user_role"，和 JSON 序列化习惯一致 - 不要存指针或未导出字段到 context，Gin 的
c.Set不做深拷贝，可能引发并发读写问题 - 若需透传完整用户结构体，确保该结构体所有字段都可序列化（比如
time.Time而非time.Unix()）
路由组加中间件为什么有时不生效
中间件必须注册在路由匹配之前，且顺序决定执行链。比如 router.Group("/api").Use(authMiddleware, loggerMiddleware) 表示所有 /api/** 请求先过鉴权，再进日志；但如果把 authMiddleware 放在 loggerMiddleware 后面，日志中间件就可能因 c.Get("user_id") 为空而 panic。
更隐蔽的问题是嵌套 Group：外层 Group("/v1").Use(auth) 对内层 Group("/admin") 生效，但反过来不行。另外，Cors() 必须放在最前，否则预检请求（OPTIONS）会被鉴权中间件拦截，报 405 Method Not Allowed。
- 登录、注册等免鉴权接口，一定不能放在
.Use(authMiddleware)的 Group 下 - 全局
router.Use()要谨慎——管理后台、健康检查等接口可能不需要鉴权 - 调试时可用
c.FullPath()打印当前匹配路径，确认中间件是否命中
真正容易被忽略的点是：中间件里调了 c.Abort() 后，绝不能再调 c.Next()，否则 handler 仍会执行。这不是“兜底”，而是逻辑失控。
