JWT中间件必须显式校验exp和iat，否则过期Token仍被接受；权限不应存于JWT而应查Redis缓存；路径需归一化处理；用户Token与服务Token须严格隔离。
JWT中间件必须校验exp和iat，否则过期Token照常通行
很多Go项目用 github.com/golang-jwt/jwt/v5 解析Token，但只调用 Parse 而没启用时间校验，导致过期Token仍被接受——这是线上最常见、最危险的漏判。v5默认不自动校验 exp 和 iat，必须显式传入验证选项。
- 正确写法：用
jwt.ParseWithClaims+jwt.WithValidMethods+jwt.WithExpirationRequired()+jwt.WithIssuedAtRequired() - 别信“我本地测试过期了会报错”——本地时钟偏移小，生产环境服务间时间差可能达数秒，建议加
jwt.WithLeeway(5 * time.Second) - 如果用HS256且密钥硬编码在代码里，
exp是唯一防重放屏障；漏掉它，等于把门虚掩着
权限检查不能塞进JWT payload，得靠外部缓存或预加载
JWT是无状态的，但权限不是静态的。把完整权限列表（如 ["user:read", "order:write"]）直接打进Token看似省事，实则埋下三颗雷：
- Token体积膨胀：10个权限就超2KB，HTTP头易触发431错误
- 权限变更无法实时生效：用户被移除角色后，旧Token在过期前一直有效
- 敏感信息泄露风险：前端若误读取Token并打印日志，
permissions字段直接暴露系统能力边界
更稳妥的做法是：JWT只放 user_id 和 role（非权限），请求进来后查Redis缓存的权限集合（key为 perms:），缓存TTL略长于Access Token（比如Token 15分钟，缓存设20分钟），既保证一致性又扛住并发。
gorilla/mux或chi路由下，路径通配匹配必须标准化
权限规则通常按路径+方法控制，比如 "GET /api/users/{id}" → "user:read"。但 chi.URLParam(r, "*") 或 r.URL.Path 返回的是原始路径，/api/users/123 和 /api/users//123、/api/users/123/ 都可能命中，而你的权限表里只写了 /api/users/{id}。
立即学习“go语言免费学习笔记（深入）”；
- 务必在中间件开头做路径归一化：
strings.TrimRight(r.URL.Path, "/")+path.Clean() - 权限配置用通配符约定：如
/api/users/*匹配所有子路径，/api/users/:id作为占位符（需配合路由库解析支持） - 别依赖
router.Use()自动透传到子router——gorilla/mux和chi都不继承，每个子router要单独调subRouter.Use(authMiddleware)
gRPC服务间调用必须隔离用户Token和服务Token
订单服务调用户服务时，绝不能把前端传来的用户JWT原样透传过去。这会导致两个问题：下游服务重复验签（性能损耗）、用户Token泄露给内部服务（越权风险）。
- 网关层验证用户JWT后，生成轻量级服务Token：
service_id="order-service", user_id="u1001", ts=time.Now().Unix()，用共享密钥HMAC签名 - 下游服务只认这个内部Token，不接触用户凭证；其鉴权中间件只需校验签名+时效，无需连DB或查权限中心
- 若已用Istio等Service Mesh，优先交由Sidecar处理mTLS+JWT，业务代码里连Token字段都不该出现
复杂点不在代码多难写，而在“哪个环节该信谁”——用户Token管身份，服务Token管链路可信，权限中心管策略，三者边界一旦模糊，审计就变成猜谜。
