推荐使用 github.com/golang-jwt/jwt/v5；HS256 密钥须≥32字节；Claims 必嵌入 jwt.RegisteredClaims；校验需显式检查 token.Valid；密钥应通过环境变量注入；中间件统一解析 token 并注入 context；RBAC 需 roles、permissions、role_permissions 三表及权限继承逻辑。
用 jwt-go 生成和校验 JWT Token
Go 中最常用的身份认证方式是基于 JWT（JSON Web Token），jwt-go 是社区主流库，但注意 v4+ 版本已弃用，推荐使用官方维护的 github.com/golang-jwt/jwt/v5。
常见错误是直接用 SigningMethodHS256 而忽略密钥长度要求——HS256 要求密钥至少 32 字节，否则会静默失败或报 crypto/hmac: invalid key size。
- 生成 token 时，
Claims必须嵌入jwt.RegisteredClaims，否则ParseWithClaims无法识别过期、签发时间等标准字段 - 校验时必须显式调用
token.Valid，仅err == nil不代表 token 有效（比如过期但签名正确） - 不要把密钥硬编码在代码里，应通过环境变量注入，例如
os.Getenv("JWT_SECRET")
package main
<p>import (
"github.com/golang-jwt/jwt/v5"
"time"
)</p><p>func generateToken(userID string) (string, error) {
claims := jwt.MapClaims{
"user_id": userID,
"exp": time.Now().Add(24 * time.Hour).Unix(),
}
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
secret := []byte("your-32-byte-secret-key-here-123456")
return token.SignedString(secret)
}</p><p>func validateToken(tokenStr string) (jwt.MapClaims, error) {
token, err := jwt.Parse(tokenStr, func(token *jwt.Token) (interface{}, error) {
return []byte("your-32-byte-secret-key-here-123456"), nil
})
if err != nil || !token.Valid {
return nil, err
}
return token.Claims.(jwt.MapClaims), nil
}用中间件实现 HTTP 请求的权限拦截
授权逻辑不能只靠前端传来的 role 字段，必须在服务端中间件中解析 token 并检查用户权限。典型错误是把权限判断写在 handler 内部，导致重复代码且易遗漏。
中间件应统一处理：解析 token → 提取 user_id 和 role → 查询数据库确认角色是否仍有效（防止 token 未过期但用户已被禁用）→ 设置 context.Context 值供后续 handler 使用。
立即学习“go语言免费学习笔记（深入）”；
- 不要用全局变量存用户信息，必须通过
context.WithValue向 request context 注入userID、role等 - 对敏感操作（如删除、支付）建议做二次校验：比如
DELETE /api/users/123需确认当前 token 的user_id是 123 或角色为 admin - 避免在中间件里做耗时 DB 查询；可先缓存常用角色权限映射（如 Redis），或使用 RBAC 模型预加载
结合 gorilla/sessions 实现服务端 Session 管理（可选替代方案）
JWT 适合无状态 API，但若需主动吊销 token 或限制登录设备数，就得引入服务端 session。此时 gorilla/sessions 仍是 Go 生态中最稳定的选择。
关键点在于 session 存储后端：默认用内存存储不适用于多实例部署；生产环境必须切换到 redisstore 或 postgresstore。
- session key 必须保密，不能用默认的
"something-very-secret"，应从环境变量读取 - 设置
Options.HttpOnly = true和Options.Secure = true（HTTPS 环境下），防止 XSS 窃取 cookie - 每次登录成功后调用
session.Save(r, w)，否则 session 不会写入响应头
RBAC 权限模型落地：如何设计 roles、permissions 和 role_permissions 表
授权不是简单比对字符串 role，而是建立可扩展的权限控制链。数据库至少需要三张表：
-
roles：存储id、name（如"admin"、"editor"） -
permissions：存储细粒度操作，如"user:read"、"post:delete" -
role_permissions：关联两者，支持一个角色多个权限、一个权限多个角色
查询时别用 N+1：一次查出用户所有权限，缓存到 context 或 token claims 中（如将 permissions 数组塞进 JWT 的 perms 字段），避免每个请求都查 DB。
容易被忽略的是权限继承问题——比如 admin 应隐式拥有 editor 所有权限。这不适合靠数据库外键解决，应在业务层写明逻辑，或用 role_hierarchy 表 + 递归查询。
