必须显式判断token.Valid，因为ParseWithClaims成功仅表示语法解析和算法匹配，不校验过期、密钥错误、alg篡改等；token.Valid为false时err仍可能为nil，漏判将导致非法token被误用。
Go 语言验证 JWT，最常踩的坑不是“不会写”，而是“以为解析成功就合法”——err == nil 只代表 token 能解码、算法匹配，token.Valid 才是最终合法性开关，漏判它，过期、签名错、alg=none 全部放行。
为什么 token.Valid 必须显式判断？
JWT 库（github.com/golang-jwt/jwt/v5）把解析和校验拆成两步：ParseWithClaims 成功只说明 header 和 payload 格式正确、签名算法没被篡改成完全不支持的类型；但以下全部不在此范围内：
-
ExpiresAt已过期 →token.Valid为false，但err仍为nil - 密钥错误或长度不足（如 HS256 密钥 token.Valid 为
false - header 中
alg被篡改为"none"（v5 已默认禁用，但若降级或配置不当仍可能绕过）→ 若未限制ValidMethods，验签被跳过，token.Valid可能为true
所以必须写：if !token.Valid { return errors.New("invalid or expired token") }，不能只靠 if err != nil。
keyFunc 怎么写才防攻击又不出 panic？
keyFunc 不只是“返回密钥”，它要同时做三件事：校验算法、加载密钥、检查密钥强度。硬编码或忽略类型断言，等于主动开后门。
立即学习“go语言免费学习笔记（深入）”；
- 先断言算法：
if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok { return nil, errors.New("invalid signing method") } - 密钥必须从环境变量读：
secret := os.Getenv("JWT_SECRET")，禁止"my-secret"字面量 - HS256 要求密钥 ≥ 32 字节：
if len(secret) - 返回值必须是
[]byte，不是string（编译报错） - 务必加
jwt.WithValidMethods([]string{jwt.SigningMethodHS256.Alg()})，否则攻击者可改 headeralg绕过验签
自定义 Claims 结构体为什么必须嵌入 jwt.RegisteredClaims？
不嵌入，exp、iat、nbf 这些字段就只是普通字段，不会触发任何自动校验逻辑 —— token.Claims.(MyClaims).ExpiresAt 可能有值，但 token.Valid() 永远返回 true，过期检查彻底失效。
- 正确写法：
type UserClaims struct { UserID string; jwt.RegisteredClaims } - 字段名必须严格匹配：
ExpiresAt（不是exp或expire_at） - 时间字段必须用
jwt.NewNumericDate()包装：ExpiresAt: jwt.NewNumericDate(time.Now().Add(1 * time.Hour)) - 解析时传指针：
&UserClaims{}，传值会导致字段赋值失败
解析后怎么安全取用户 ID？
token.Claims 是 interface{}，直接访问 claims.UserID 会 panic。类型断言失败比你想象中更常见，尤其生成和解析用的结构体不一致时。
- 必须做类型断言：
claims, ok := token.Claims.(*UserClaims); if !ok { return errors.New("failed to cast claims") } - 断言成功后，仍要检查关键字段是否为空：
if claims.UserID == "" { return errors.New("user_id missing") } - 别跳过
token.Valid判断 —— 断言成功但token.Valid == false仍是非法 token - 敏感操作前建议查库确认用户状态（如是否被禁用），JWT 不代表实时权限
真正容易被忽略的，是 keyFunc 里那行 len(secret) 校验 —— 没它，HS256 在某些运行时会静默失败，token 看似有效实则验签跳过，线上排查起来极难定位。
