jwt-go v3.2.0 是最后一个稳定版，需显式校验 alg 字段并使用至少 32 字节密钥；微服务应签发精简短时效下游 Token；须自定义 Claims 结构体、缓存解析结果与密钥，避免 Token 过大。
Go 里用 jwt-go 生成和解析 Token 容易踩哪些坑
别直接上 jwt-go v4 或 v5 —— 官方已归档，v3.2.0 是最后一个稳定版，且默认不校验 alg 字段，攻击者可篡改为 none 导致签名校验失效。必须显式设置 Verify 并传入白名单算法（如 jwt.SigningMethodHS256），否则 Parse 会静默接受非法签名。
常见错误现象：token.Valid 返回 true，但实际是 none 算法伪造的；或解析时 panic 报 "square/go-jose: error in cryptographic primitive"，本质是密钥长度不足（HS256 要求至少 32 字节）。
- 用
jwt.ParseWithClaims(tokenString, &MyClaims{}, func(*jwt.Token) (interface{}, error) { return []byte(secret), nil })，别省略第三个参数里的密钥回调 - 密钥建议用
crypto/rand.Read生成 32 字节随机字节，而非硬编码字符串（如"my-secret"不安全） - 解析后务必检查
err == nil && token.Valid，且手动验证token.Header["alg"]是否在预期范围内
微服务间透传 JWT 时，如何避免 Token 泄露和重放
HTTP Header 里传 Authorization: Bearer <token> 是标准做法，但服务间调用不能复用前端发来的原始 Token —— 它可能含敏感字段（如 email）、过期时间长、签名密钥与内部服务不一致。
正确做法是：网关层（或认证服务）校验原始 Token 后，生成一个短时效（如 5 分钟）、精简 Claims（只保留 sub、service_id、scope）、用内部密钥重签名的「下游 Token」，再注入到 gRPC metadata 或 HTTP Header 中传递。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别把原始 Token 直接塞进
context.WithValue向下传 —— 日志、panic 捕获可能意外打印它 - gRPC 场景下，用
metadata.Pairs("authorization", "Bearer "+innerToken)透传，接收方用metadata.FromIncomingContext提取 - 重放防护靠
iat+exp+ 服务端滑动窗口（如 Redis 记录最近 1 分钟已用过的jti）
为什么 Go 的 jwt.StandardClaims 不该直接用于微服务通信
jwt.StandardClaims 字段太少，且 Issuer、Audience 是字符串，没法表达多服务场景下的细粒度权限。比如 A 服务调 B 服务，B 需确认 Token 确实由网关签发（iss=api-gateway），且明确授权给 aud=payment-service，否则任意服务都能伪造请求。
更麻烦的是，StandardClaims 没法嵌套结构体，而微服务常需带 permissions: ["order:read", "user:write"] 或 tenant_id: "t-123" 这类业务字段。
- 自定义 Claims 结构体，内嵌
jwt.StandardClaims，再加Permissions []string、TenantID string等字段 - 注册时用
jwt.RegisterCustomClaims(&MyClaims{})（非必需，但利于类型安全） - 生成 Token 时，用
token := jwt.NewWithClaims(jwt.SigningMethodHS256, MyClaims{...})显式指定类型
JWT 解析性能差？不是库的问题，是用法错了
单次 Parse 在现代 CPU 上耗时约 10–50μs，瓶颈从来不在 JWT 库本身，而在密钥加载、网络 IO 或没做缓存。比如每次解析都从环境变量读密钥、或每次请求都查数据库拿公钥，这才是真慢。
另一个隐形成本：频繁解析同一 Token（如中间件校验后，业务逻辑又解析一遍）—— Go 没有类似 Python 的 request.jwt 属性缓存机制，得自己存到 context。
- 密钥提前加载到全局变量或配置结构体里，别在
Parse回调里实时读 - 解析成功后，把
*MyClaims存进context.WithValue(ctx, jwtKey, claims)，后续 Handler 直接取，别重复解析 - 如果用 RSA 公钥验签，把
*rsa.PublicKey缓存在内存（别每次从 PEM 文件解析），可用sync.Once初始化
最常被忽略的一点：Token 本身不该包含大量数据。超过 1KB 的 JWT 会显著拖慢 HTTP 头解析、增加 gRPC metadata 传输开销，也更容易触发某些代理的 header 截断限制。权限信息尽量用 ID 查，别全塞进 Token。
