gin中间件无法透传jwt结果是因为其返回值为void，必须通过c.set()或c.request.context()传递数据；parsejwt需线程安全且缓存公钥；rbac应分层实现，认证与授权分离；c.next()后代码在整条链执行完才运行，适合审计日志等收尾操作。
为什么 Gin 的 gin.HandlerFunc 不能直接透传 JWT 解析结果？
因为 Gin 中间件的返回值是 void，所有上下文数据必须写入 c.Request.Context() 或 c.Set() 才能被后续 handler 获取。常见错误是解析完 token 后只存局部变量，导致 handler 里拿不到 user_id 或 roles。
正确做法是统一用 c.Set("user_id", uid) 或更推荐的 c.Set("claims", claims)（claims 是解析出的 map[string]interface{}）。注意：不要用 c.Request.Header.Set() 修改 header，那是只读的，且不安全。
示例片段：
func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
tokenString := c.GetHeader("Authorization")
if tokenString == "" {
c.AbortWithStatusJSON(401, gin.H{"error": "missing auth header"})
return
}
// 去掉 "Bearer " 前缀
tokenString = strings.TrimPrefix(tokenString, "Bearer ")
claims, err := ParseJWT(tokenString) // 自定义解析函数
if err != nil {
c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"})
return
}
c.Set("claims", claims) // ✅ 关键：挂载到 context
c.Next()
}
}
如何避免 ParseJWT 被重复调用或并发 panic？
JWT 解析本身不耗时，但若没做 key 缓存或验签失败时 panic，会在高并发下拖垮服务。Gin 中间件默认每请求执行一次，所以 ParseJWT 必须是幂等、无状态、线程安全的。
关键点：
-
jwt.Parse内部会调用keyFunc，该函数务必返回缓存后的公钥（如从sync.Map读取），避免每次 IO 加载 PEM - 不要在
keyFunc里 panic，应返回nil, err；否则 Gin 会触发 recover，掩盖真实错误 - 验签失败时，
err类型可能是*jwt.ValidationError，可据此区分过期（errors.Is(err, jwt.ErrTokenExpired)）和签名无效
建议结构：
var keyMap sync.Map // key: kid, value: *rsa.PublicKey
func ParseJWT(tokenStr string) (jwt.MapClaims, error) {
token, err := jwt.Parse(tokenStr, func(t *jwt.Token) (interface{}, error) {
kid, _ := t.Header["kid"].(string)
if pk, ok := keyMap.Load(kid); ok {
return pk.(*rsa.PublicKey), nil
}
pk, loadErr := LoadPublicKey(kid) // 从配置或远程加载
if loadErr != nil {
return nil, loadErr
}
keyMap.Store(kid, pk)
return pk, nil
})
if err != nil {
return nil, err
}
if !token.Valid {
return nil, errors.New("token invalid")
}
return token.Claims.(jwt.MapClaims), nil
}
RBAC 权限校验该放在中间件还是 handler 里？
放在中间件里更高效，但必须分层：认证（AuthN）和授权（AuthZ）分离。Gin 中间件适合做「是否登录」，而「是否有某接口权限」建议用独立中间件链或装饰器模式，避免把所有逻辑塞进一个 AuthMiddleware。
典型分法：
-
AuthMiddleware：只做 token 解析 + 用户身份注入（c.Set("user_id", ...)） -
RoleRequired("admin")：接收角色名，从c.MustGet("claims")提取roles字段比对 -
PermissionRequired("order:write")：查用户权限表或 RBAC 规则引擎（如 casbin），需异步调用，建议加缓存
错误示例：在 AuthMiddleware 里硬编码 if role != "admin" { abort } —— 违反单一职责，无法复用。
为什么 c.Next() 后续的代码常被忽略或执行异常？
因为 c.Next() 是同步阻塞调用，它执行完所有后续中间件和 handler 后才继续往下走。很多开发者误以为它像 goroutine 一样“发出去就不管了”，结果在 c.Next() 后写日志或清理逻辑时，发现 c.Writer.Status() 已经是 200，甚至 response body 已写出。
真正需要“收尾”的场景（如审计日志、指标打点）应使用 c.Next() 后的代码块，并检查 c.IsAborted() 和 c.Writer.Status()：
func AuditLog() gin.HandlerFunc {
return func(c *gin.Context) {
start := time.Now()
c.Next() // 等待整个 chain 执行完
if c.IsAborted() {
// 可能被前面中间件 abort，比如鉴权失败
log.Warn("audit skipped due to abort")
return
}
status := c.Writer.Status()
duration := time.Since(start)
log.Info("request", "path", c.Request.URL.Path, "status", status, "duration", duration)
}
}
微服务环境下，这个位置也是注入 traceID、上报 metrics 的黄金点——但别在这里做耗时操作，否则拖慢整个请求链路。
