最常用go Web认证方案是gin搭配golang-jwt/jwt：登录签发带ExpiresAt的Token，中间件校验并注入user_id；密码必须用bcrypt哈希（cost=12）；session更重且需防csrf/fixation；权限复杂时应选casbin而非硬编码RBAC。
用 gin + jwt-go 实现登录签发与中间件鉴权
Go Web 项目最常用、也最轻量的认证组合就是 gin 搭配 jwt-go（或更推荐的 golang-jwt/jwt）。核心逻辑分两步：登录成功后生成 token，后续请求通过中间件解析并校验 token 中的 user_id 或 role 字段。
关键注意点：
-
jwt-gov4+ 已归档，生产环境建议迁移到github.com/golang-jwt/jwt/v5 - secret key 必须足够长且保密，不要硬编码在代码里，应从环境变量读取（如
os.Getenv("JWT_SECRET")） - token 签发时务必设置
ExpiresAt，避免长期有效凭证泄露后无法回收 - 中间件中解析失败（如签名错误、过期、字段缺失）必须直接
c.AbortWithStatusjsON(401, ...)，不能继续往下走
func JWTAuth() gin.HandlerFunc { return func(c *gin.Context) { authHeader := c.GetHeader("Authorization") if authHeader == "" { c.AbortWithStatusjson(401, gin.H{"error": "missing Authorization header"}) return } tokenString := strings.TrimPrefix(authHeader, "Bearer ") token, err := jwt.Parse(tokenString, func(t *jwt.Token) (interface{}, error) { if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok { return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"]) } return []byte(os.Getenv("JWT_SECRET")), nil }) if err != nil || !token.Valid { c.AbortWithStatusJSON(401, gin.H{"error": "invalid or expired token"}) return } if claims, ok := token.Claims.(jwt.MapClaims); ok { c.Set("user_id", uint(claims["user_id"].(float64))) c.Next() } else { c.AbortWithStatusJSON(401, gin.H{"error": "invalid token claims"}) } } }如何安全存储密码 —— 用 golang.org/x/crypto/bcrypt 哈希
绝对不能明文存密码，也不能用 MD5/SHA 等快哈希。Go 官方推荐的唯一方案是 bcrypt，它自带 salt 且可调成本因子（cost=12 是当前合理默认值）。
常见误操作：
立即学习“go语言免费学习笔记（深入）”；
- 注册时没调用
bcrypt.GenerateFromPassword，直接存原文 - 登录比对时用了
==或strings.EqualFold，正确做法是bcrypt.CompareHashAndPassword - 把
cost设得过高（如 20），导致单次登录耗时 >500ms，易被 DoS
// 注册 hashed, err := bcrypt.GenerateFromPassword([]byte(password), 12) if err != nil { return err } db.Exec("INSERT INTO users (username, password_hash) VALUES (?, ?)", username, string(hashed)) // 登录 var hash string db.QueryRow("SELECT password_hash FROM users WHERE username = ?", username).Scan(&hash) if err := bcrypt.CompareHashAndPassword([]byte(hash), []byte(password)); err != nil { return errors.New("invalid credentials") }为什么不用 Session？http.cookie + redis 的坑在哪
Session 方案在 Go 里并非不能做，但相比 JWT 更重：你需要维护服务端状态、处理并发写入、考虑 redis 故障降级、还要防 session fixation 和 CSRF（即使用 SameSite=Lax 也不完全免疫）。
若坚持用 Cookie Session，必须做到：
- session id 用
http.SetCookie设置时，HttpOnly=true、Secure=true（https 环境）、SameSite=SameSiteStrictMode或SameSiteLaxMode - session 数据存在 redis 时，key 要加前缀（如
sess:），并设 TTL（建议略长于 cookie 过期时间） - 每次登录成功后必须生成新 session id（防止 fixation），老 session 要主动删除
- 所有敏感操作（改密、删账号）必须二次验证，不能只依赖 session 存活
权限控制粒度：从 RBAC 到 casbin 的取舍
简单项目用 if-else 判断 c.GetInt64("role") == 1 就够了；但一旦角色变多、资源路径动态化（如 `/api/v1/org/:id/project`）、或需支持用户级权限（非角色继承），手写判断会迅速失控。
casbin 是 Go 生态最成熟的授权库，它把「谁（subject）对什么（Object）能做什么（action）」抽象成策略规则，支持 ACL、RBAC、ABAC 多种模型。
要注意的现实约束：
- 策略加载时机很重要：全量从 DB 加载一次缓存即可，别每次请求都查
- casbin 的
Enforce调用本身很快（微秒级），但如果你在每条路由里都写e.Enforce(...)，容易掩盖真实瓶颈（比如 DB 查询） - 不要用 casbin 做登录态管理——它只管“能做什么”，不管“是不是本人”
- 调试时打开
e.EnableLog(true)，看实际匹配了哪条 policy
真正难的不是集成 casbin，而是设计出不互相冲突、可审计、能随业务演进的 policy 表结构和加载逻辑。