ParseWithClaims第二个参数必须传结构体指针，且claims字段需嵌入jwt.RegisteredClaims；解析后须用token.Claims.(*CustomClaims)断言，再校验token.Valid和字段有效性。
ParseToken 时 panic: interface conversion: interface {} is *jwt.Token, not *request.CustomClaims
这是最常遇到的类型断言失败，根源在于 jwt.ParseWithClaims 的第二个参数传了指针类型但内部没正确解包。你写了 &request.CustomClaims{}，但库实际返回的是 *jwt.Token，而它的 Claims 字段才是你要的结构体指针。
- 必须确保传入的 claims 实例地址和最终赋值目标一致：用
claims := &request.CustomClaims{}，再传claims给ParseWithClaims - 回调函数里返回的
j.SigningKey必须是[]byte类型，不能是string—— 否则jwt-gov5 会静默失败或 panic - 如果用了
github.com/golang-jwt/jwt/v5，注意ParseWithClaims第三个参数是func(token *jwt.Token) (any, error)，返回值类型必须是any（即interface{}），且不能返回nilkey
HS256 签名验签失败但 token 看起来格式正确
token 能 Base64 解码、结构完整，却过不了 ParseWithClaims，大概率是密钥不匹配或算法误配。微服务网关通常复用同一套 JWT 配置，但各服务可能加载了不同版本的配置项。
- 检查
global.Config.JWT.SigningKey是否被 trim 过空格或换行符 ——strings.TrimSpace必须显式调用 - 确认所有服务使用的库版本统一：
github.com/golang-jwt/jwt/v5和github.com/dgrijalva/jwt-go不兼容，后者已归档，v5 的SigningMethodHS256值是"HS256"字符串，不是常量 - Header 中的
alg必须与代码中指定的 signing method 完全一致；若 token 是用 RS256 签的，却用 HS256 解析，会直接报ErrTokenInvalid
高并发下 ParseToken 性能卡在 crypto/hmac
网关每秒处理数千请求，ParseToken 成为瓶颈，profiling 显示大量时间花在 crypto/hmac 计算上 —— 这说明你在每次解析时都新建了 HMAC 实例，没复用底层 hash 对象。
-
jwt-gov5 默认每次调用都新建 hasher，无法复用；解决方案是改用预构建的jwt.SigningMethod实例，例如：var hs256 = jwt.GetSigningMethod("HS256").(*jwt.SigningMethodHMAC)，然后在验证时显式传入 - 更彻底的优化：把密钥转成
hmac.Hash实例缓存起来，避免每次调用都hmac.New；但要注意密钥不可变且线程安全 - 别忽略 token 提前校验：先用
strings.Count(tokenString, ".") == 2快速过滤非法格式，再进 full parse 流程
微服务间传递 JWT 时 issuer 校验失败
网关签发的 token，在下游服务 ParseToken 时因 Issuer 不匹配被拒绝，但两边配置明明一样。问题往往出在字符串比较的隐式差异上。
立即学习“go语言免费学习笔记（深入）”；
-
global.Config.JWT.Issuer在 YAML 配置里若写成issuer: "auth.example.com"，Go 加载后可能带末尾换行或 BOM；建议在初始化时用strings.TrimSpace归一化 - 下游服务若没显式设置
ValidFuncs，默认只校验exp和iat，iss不校验；必须手动加：claims.VerifyIssuer(global.Config.JWT.Issuer, true) - 网关作为统一签发方，应固定使用单一
Issuer字符串（如"gateway"），避免各服务自行配置导致不一致
