JWT中间件需显式校验token.Valid，用ParseWithClaims解析自定义Claims，正确提取Bearer Token并防护空值，存取用户ID应类型安全断言，时间戳须用秒级int64。
JWT中间件怎么写才不绕过校验
直接用 gin.HandlerFunc 包一层，但很多人漏掉对 token.Valid 的显式判断，导致签名失效或过期的 token 仍被放行。
关键不是解析成功，而是验证通过。Go 的 jwt.Parse 默认只做结构解析，Valid 字段必须手动检查。
- 务必在解析后加
if !token.Valid { c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"}) } - 别把
Parse和ParseWithClaims混用：前者返回原始*jwt.Token，后者才能绑定自定义 claims 结构 - 如果用了
SigningMethodHS256，密钥长度建议 ≥32 字节，否则 Go 的 crypto/hmac 会静默截断，导致本地测试通、线上校验失败
如何从 Authorization Header 正确提取 token
前端发来的 Authorization: Bearer xxx，Gin 默认不自动拆解，得自己切分字符串——但空格位置、大小写、前缀缺失都容易出错。
常见错误现象：token is empty 或 square/go-jose: error in cryptographic primitive（其实是传了 Bearer 整个字符串去解析）。
立即学习“go语言免费学习笔记（深入）”；
- 用
c.Request.Header.Get("Authorization")取值，再按空格分割，取索引 1；别用c.GetHeader（行为一致但语义弱） - 加空值防护：
if len(parts) != 2 || parts[0] != "Bearer" { ... }，避免parts[1]panic - 注意某些代理或测试工具（如 curl 不带空格）可能发
Bearerxxx，生产环境建议加日志打点，记录原始 header 值
自定义 Claims 结构体为什么总解析失败
用 jwt.MapClaims 能跑通，但换成 struct 就报 json: cannot unmarshal string into Go struct field，本质是字段没导出或 tag 写错。
Go 的 json 解析要求字段首字母大写 + 显式 json tag，且 JWT payload 里的 key 名（如 exp）必须完全匹配。
- claims struct 所有字段必须大写开头，例如
Exp int64 `json:"exp"`，小写exp字段会被忽略 -
StandardClaims已内置ExpiresAt等字段，继承它比手写更稳：type CustomClaims struct { jwt.StandardClaims; UserID uint `json:"user_id"` } - 解析时用
jwt.ParseWithClaims(tokenString, &claims, keyFunc)，别漏掉&claims的取地址符，否则 struct 不会被填充
Gin 中间件里怎么安全存取用户 ID
很多人用 c.Set("user_id", id)，但后续 handler 里用 c.GetInt("user_id") 会 panic——因为 Set 存的是 interface{}，类型不匹配。
真正安全的方式是统一用 c.MustGet + 类型断言，或者封装一个强类型 context。
- 存：用
c.Set("user_id", uint(123))，确保是具体类型，不是int（32/64 位平台不一致） - 取：必须
if id, ok := c.MustGet("user_id").(uint); ok { ... }，别跳过ok判断 - 更推荐：定义
type contextKey string; const userIDKey contextKey = "user_id"，用c.Request.Context().Value(userIDKey)，避免 key 冲突和类型擦除
JWT 的 exp、iat 时间戳全是秒级 int64，但 Go 的 time.Unix() 默认纳秒，一不留神就把过期时间设成公元 1970 年——这种 bug 不报错，只默默拒绝所有请求。
