权限控制听起来是个老生常谈的话题，但真正落地到代码层面，很多Go项目的做法其实并不严谨。有的项目只在登录接口做了校验，后面的业务接口全部裸奔；有的把角色判断硬编码散落在各个Handler里，一旦权限规则变化就要满文件改代码。这篇文章以Gin框架为例，把权限控制拆成认证和授权两步，用JWT解决身份识别问题，用Casbin解决权限判定问题，并给出可以直接跑起来的代码示例。
一、先厘清认证与授权的区别
很多人把认证和授权混为一谈，这是权限体系设计中最常见的误区。认证回答的是"你是谁"，也就是确认请求方确实是他声称的那个用户，常见手段有Session、JWT、OAuth2等；授权回答的是"你能干什么"，即在已知身份的前提下，判断这个用户有没有权限访问某个资源或执行某个操作。
两者的实现位置也不同。认证通常做成全局中间件，挂在路由组的入口处，统一拦截未登录请求；授权则更细粒度，可能针对不同接口、不同HTTP方法甚至不同数据行做判断。举个具体例子：一个电商后台系统，运营人员登录成功属于认证，而他能否访问"订单退款"接口、能否操作别人的订单，这些属于授权范畴。认证失败应返回401，授权失败应返回403，这两个状态码不要混用，否则前端很难区分该跳转登录页还是提示无权限。
理解了这个分层，代码结构也就清晰了：先写一个JWT认证中间件把用户身份解析出来塞进请求上下文，再写一个授权层基于用户身份做权限判定。下面分别展开。
二、用JWT中间件实现认证
JWT由Header、Payload、Signature三部分组成，服务端签发后不需要存储会话状态，天然适合分布式场景。Go社区里用得最多的是github.com/golang-jwt/jwt/v5这个库。先封装一个签发Token的函数：
package auth
import (
"errors"
"time"
"github.com/golang-jwt/jwt/v5"
)
var secret = []byte("your-256-bit-secret") // 生产环境应从配置读取
type Claims struct {
UserID int64 `json:"user_id"`
Username string `json:"username"`
jwt.RegisteredClaims
}
// GenerateToken 签发JWT
func GenerateToken(userID int64, username string) (string, error) {
claims := Claims{
UserID: userID,
Username: username,
RegisteredClaims: jwt.RegisteredClaims{
ExpiresAt: jwt.NewNumericDate(time.Now().Add(24 * time.Hour)),
IssuedAt: jwt.NewNumericDate(time.Now()),
},
}
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
return token.SignedString(secret)
}
// ParseToken 解析并校验JWT
func ParseToken(tokenString string) (*Claims, error) {
token, err := jwt.ParseWithClaims(tokenString, &Claims{},
func(t *jwt.Token) (interface{}, error) {
if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, errors.New("非法的签名算法")
}
return secret, nil
})
if err != nil || !token.Valid {
return nil, errors.New("token无效或已过期")
}
claims, ok := token.Claims.(*Claims)
if !ok {
return nil, errors.New("claims类型断言失败")
}
return claims, nil
}注意解析函数里对签名算法的校验不能省略。JWT存在一个经典的alg混淆漏洞：攻击者把Header中的算法改成none或RS256，如果服务端不检查算法类型直接按声明的算法解析，就可能被伪造的Token绕过认证。上面代码中通过t.Method.(*jwt.SigningMethodHMAC)强制限定为HMAC家族，是防御这类攻击的关键一行。
接着在Gin中封装成中间件，从请求头取Token、解析成功后把用户信息写入上下文：
func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
authHeader := c.GetHeader("Authorization")
if authHeader == "" || !strings.HasPrefix(authHeader, "Bearer ") {
c.AbortWithStatusJSON(401, gin.H{"code": 401, "msg": "未登录"})
return
}
tokenString := strings.TrimPrefix(authHeader, "Bearer ")
claims, err := auth.ParseToken(tokenString)
if err != nil {
c.AbortWithStatusJSON(401, gin.H{"code": 401, "msg": err.Error()})
return
}
// 用户信息写入上下文，后续Handler可直接读取
c.Set("user_id", claims.UserID)
c.Set("username", claims.Username)
c.Next()
}
}使用时把需要登录的路由挂到中间件之后即可：
r := gin.Default()
api := r.Group("/api")
api.Use(AuthMiddleware())
{
api.GET("/orders", ListOrders)
api.POST("/refund", CreateRefund)
}三、用Casbin实现RBAC授权
认证通过只代表用户合法，接下来要判断他有没有权限访问目标接口。简单项目可以在中间件里写死角色判断逻辑，比如if role != "admin" { ... }，但角色和权限一旦需要动态管理，硬编码就彻底失控了。Casbin是一个支持RBAC、ABAC等多种权限模型的开源授权库，Go版本是github.com/casbin/casbin/v2，它把权限规则和代码逻辑解耦，规则调整时不需要改代码，只需修改策略数据。
Casbin的权限模型定义在一个配置文件里，下面是最常用的RBAC模型：
[request_definition] r = sub, obj, act [policy_definition] p = sub, obj, act [role_definition] g = _, _ [policy_effect] e = some(where (p.eft == allow)) [matchers] m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
这段配置的含义是：请求由主体（用户或角色）、客体（接口路径）、动作（HTTP方法）三元组构成；策略p定义了谁对什么资源有什么权限；g定义用户与角色的绑定关系；matcher里通过g(r.sub, p.sub)实现角色继承，用户继承了某角色，就拥有该角色的全部权限。
策略数据可以放在CSV文件里，也可以放数据库。下面是CSV形式的示例：
p, admin, /api/orders, GET p, admin, /api/refund, POST p, operator, /api/orders, GET g, alice, admin g, bob, operator
意思是：admin角色可以查询订单和发起退款，operator角色只能查询订单；alice绑定admin角色，bob绑定operator角色。然后在Gin中写一个授权中间件，把请求路径和方法传给Casbin判定：
var enforcer *casbin.SyncedEnforcer
func InitCasbin() error {
e, err := casbin.NewSyncedEnforcer("rbac_model.conf", "rbac_policy.csv")
if err != nil {
return err
}
enforcer = e
return nil
}
func CasbinMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
userID := c.GetInt64("user_id")
obj := c.Request.URL.Path
act := c.Request.Method
ok, err := enforcer.Enforce(fmt.Sprintf("user:%d", userID), obj, act)
if err != nil || !ok {
c.AbortWithStatusJSON(403, gin.H{"code": 403, "msg": "无权限"})
return
}
c.Next()
}
}两个中间件串联使用：认证中间件在前，授权中间件在后。这样请求进来先确认身份，再判定权限，职责分明。策略需要动态变更时，可以调用enforcer.AddPolicy、enforcer.AddGroupingPolicy等API在运行时增删规则，配合casbin-gorm-adapter还能把策略持久化到MySQL等数据库，实现后台管理界面直接配置权限。
四、权限数据的组织与进阶细节
实际项目中，权限数据一般落库存储，典型表结构包括：用户表、角色表、用户角色关联表、权限表（记录接口路径和方法的组合）、角色权限关联表。管理后台对这些表做增删改查，变更时同步刷新Casbin的策略，这是RBAC管理系统的标准做法。相比直接把策略写在CSV里，落库方案支持可视化配置，也更符合运维习惯。
另一个容易被忽视的问题是接口权限和数据权限的区别。上面整套方案控制的是接口级权限，即能不能访问这个接口；但很多业务还需要数据级权限，比如运营人员只能查看自己负责的门店订单。数据权限无法靠统一中间件拦截，通常要在业务查询里注入过滤条件，例如从上下文取出用户ID，在SQL的where子句中追加store_id = ?之类的限制。如果条件较多，可以用Golang的代码生成或泛型封装统一的查询Scope，避免每个查询都手写一遍。
性能方面有两点建议。第一，Casbin每次Enforce都要遍历策略做匹配，策略量大时会成为瓶颈，生产环境务必启用SyncedEnforcer并考虑开启策略缓存，或者把常用角色的判定结果缓存到内存。第二，JWT的过期与登出问题需要单独处理：JWT本身无状态，签发后无法主动作废，常见的补救方案是维护一个Redis黑名单，登出或踢人时把Token写入黑名单，认证中间件解析成功后再查一次黑名单。虽然多了一次Redis查询，但换来了主动失效能力，这个代价通常是值得的。
总结一下，一套完整的Golang Web权限体系可以概括为：JWT中间件负责认证、Casbin负责接口级授权、业务层负责数据级权限，三者各司其职又层层递进。从小项目到大系统，这套结构都能平滑扩展，需要做的只是把策略存储从文件换成数据库、把权限粒度从接口细化到字段而已。
Golang权限控制JWT认证Casbin修改时间：2026-09-15 13:24:45