JWT 的 exp 字段被忽略主因是未检查 token.Valid 或未启用时间校验；Go 中需显式调用 token.Valid 并配置 jwt.WithExpirationRequired()，同时确保系统时间同步。
为什么 JWT 中的 exp 字段总被忽略？
Go 微服务里用 jwt-go（v3 或 v4）校验 token 时，exp 不生效，请求仍能通过——大概率是没调用 token.Valid，或漏了 ParseWithClaims 的验证选项。
正确做法是显式传入 jwt.WithValidMethods 和校验回调，例如：
token, err := jwt.ParseWithClaims(
tokenString,
&MyClaims{},
func(token *jwt.Token) (interface{}, error) {
return []byte(secret), nil
},
jwt.WithValidMethods([]string{jwt.SigningMethodHS256.Alg()}),
)
if err != nil || !token.Valid {
return errors.New("invalid token")
}
-
token.Valid必须手动检查，它不自动触发exp/nbf校验 - v4 默认关闭时间校验，需在
ParseOptions中启用jwt.WithExpirationRequired() - 系统时间偏差超过 5 秒会导致
exp失效，建议微服务统一 NTP 同步
如何让 Gin 中间件统一拦截未授权请求？
Gin 的 gin.HandlerFunc 要覆盖所有路由，但容易漏掉 OPTIONS 预检、健康检查路径或静态资源路由，导致鉴权绕过。
推荐结构：
立即学习“go语言免费学习笔记（深入）”；
func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
// 跳过白名单路径
path := c.Request.URL.Path
if strings.HasPrefix(path, "/health") || path == "/metrics" {
c.Next()
return
}
tokenString := c.GetHeader("Authorization")
if tokenString == "" {
c.AbortWithStatusJSON(401, gin.H{"error": "missing Authorization header"})
return
}
// 解析并校验 token（复用上一节逻辑）
claims, err := parseAndValidateToken(tokenString)
if err != nil {
c.AbortWithStatusJSON(401, gin.H{"error": err.Error()})
return
}
c.Set("user_id", claims.UserID)
c.Set("roles", claims.Roles)
c.Next()
}
}
- 白名单必须显式定义，不能只靠
router.Use()顺序控制 - 不要在中间件里直接写
c.JSON(401, ...)后调用c.Next()，会继续执行后续 handler - 用
c.Set()传递用户上下文，比全局 map 或 context.WithValue 更 Gin 原生
RBAC 权限检查该放在网关层还是服务内？
单体网关（如 Kong、Traefik 插件）做 RBAC 简单但僵硬：无法感知业务字段级权限（比如 “只能查自己创建的订单”），且策略变更要重启网关。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
更可行的是分层控制：
- 网关层做粗粒度路由级鉴权（
POST /api/v1/orders→ 角色admin或seller） - 服务内 handler 做细粒度数据级鉴权（查
order_id=123时，校验claims.UserID == order.UserID） - 共用一套权限规则定义（如 Open Policy Agent 的
.rego文件），避免策略散落
Go 服务中可封装一个 CheckPermission(ctx context.Context, action string, resourceID string) error，内部调用 OPA HTTP API 或本地评估器。
服务间调用如何透传用户身份而不被伪造？
HTTP Header 里的 Authorization 在服务 A → B 调用时若直接透传，B 无法区分是终端用户发起的原始请求，还是 A 自己构造的伪造请求。
标准解法是使用双向 TLS + mTLS 身份绑定，或更轻量的：服务间用短期 service token + 用户上下文签名：
- A 从原始请求解析出
user_id、roles，生成一个 5 分钟有效期的 JWT，用服务间共享密钥签名 - A 调用 B 时，把该 token 放在
X-Service-Token头，原始Authorization头丢弃 - B 只信任
X-Service-Token，并从中提取user_id继续下游鉴权
这样既避免 header 伪造，又不用改全链路 TLS 配置。关键是所有服务必须严格校验 X-Service-Token 的签发者和有效期，且禁止回传给终端用户。
