优先选HS256而非RS256，因其快约40%、验证稳定在0.02ms；无密钥分发或第三方验签需求时不必用RS256；密钥需预加载为[]byte，Token解析前须做格式校验和Base64解码拦截，避免重复解析与内存浪费。
JWT签名算法选HS256而不是RS256
HS256比RS256快约40%，验证耗时稳定在0.02ms量级，而RS256因非对称加解密开销大，在高并发下容易成为瓶颈。除非你有明确的密钥分发或第三方验签需求（比如OAuth 2.0 Provider场景），否则别默认上RS256。
实操建议：
-
jwt.SigningMethodHS256是 Gin +github.com/golang-jwt/jwt/v5的默认且最稳妥选择 - 密钥必须用
[]byte("your_secret_key")形式预加载，避免每次解析都重复转字节切片 - 如果要用RS256，私钥必须用
rsa.PrivateKey类型加载并缓存，不能每次从文件读取再解析
Token解析前先做快速格式校验
直接调 jwt.Parse() 会触发完整解码+签名验证流程，但很多非法请求连基本结构都不满足（比如少一个点、Base64非法字符、头部不是JSON）。提前拦截能省下大量CPU。
常见错误现象：日志里频繁出现 token contains an invalid number of parts 或 illegal base64 data
实操建议：
- 用
strings.Count(tokenString, ".") != 2快速筛掉明显非法Token - 对三段分别做
base64.RawURLEncoding.DecodeString()尝试解码，捕获base64.CorruptInputError并提前c.Abort() - 不要在中间件里对每个请求都调
jwt.Parse()，尤其没做任何前置过滤时
避免在中间件里重复解析同一Token多次
Gin中间件链中，如果后续 handler 又调一次 ValidateToken()，等于把签名验证跑两遍。更隐蔽的是：某些日志中间件或审计中间件也会偷偷读 c.Get("user_id")，但没意识到这个值本应来自已验证过的Token。
使用场景：你在 AuthMiddleware 里解析完Token，把 user_id 存进 c.Set("user_id", userID)，但另一个 LogMiddleware 又自己去Header里取Token重验
实操建议：
- 所有下游逻辑统一从
c.MustGet("user_id").(string)拿用户标识，而非重新解析Token - 在
AuthMiddleware结尾加个标记，比如c.Set("auth_validated", true)，其他中间件检查这个标记再决定是否跳过验证 - 如果必须支持“无Token时走游客模式”，也要确保游客ID是硬编码或UUID生成，而不是每次调
uuid.New()—— 它虽快，但没必要在每请求里调
密钥和Token解析结果要复用，别每次都new
JWT库内部会为每次 jwt.Parse() 创建新 *jwt.Token 实例，而签名验证函数（func(*jwt.Token) (interface{}, error)）如果每次都返回新密钥切片，会触发额外内存分配。
性能影响：压测时GC频率升高，pprof能看到大量 runtime.mallocgc 占比突增
实操建议：
- 把密钥声明为包级变量：
var jwtSecret = []byte(os.Getenv("JWT_SECRET"))，避免重复[]byte()转换 - 如果用
MapClaims，别写jwt.MapClaims{"user_id": userID}在热路径里；高频场景考虑预定义 struct 并复用实例（虽然多数情况 MapClaims 已足够轻） - 不用
jwt.ParseWithClaims()带泛型参数的版本做热路径解析——它会多一层反射开销，jwt.Parse()+ 类型断言更直接
复杂点在于：性能优化容易和安全要求冲突。比如跳过完整解析能提速，但可能漏掉某些边缘篡改；复用密钥方便，但密钥轮换时就得重启服务。这些取舍没法一刀切，得看你的QPS阈值、密钥更新频率、以及能否接受极低概率的误放行。
