在 Go 管理后台里落地 Casbin RBAC

这里有几个点我会特别在意：

1. sync.Once 用来保证初始化只发生一次，不然线上很容易撞重复创建。
2. gorm-adapter 直接接 MySQL，策略不用单独再维护一套存储。
3. EnableAutoSave(true) 能省掉手动写库的麻烦，但它只管保存，不会替你刷新内存里的策略。
4. 模型文件和代码分离后，权限规则改起来会轻一点，这点在后台系统里很实用。

Gin 中间件里做权限校验

权限检查一般放在中间件里，路由层最清楚请求长什么样，也最适合在这里拦掉无效访问。

// internal/middleware/admin_auth.go
func AdminAuthHandler() gin.HandlerFunc {
	return func(c *gin.Context) {
		// 1. 获取用户信息
		uid := c.GetUint("uid")
		if uid == 0 {
			response.Fail(c, e.NotLogin, "请先登录")
			c.Abort()
			return
		}
		adminUser := getUserFromContext(c)
		if adminUser == nil {
			response.Fail(c, e.NotLogin, "登录已失效，请重新登录")
			c.Abort()
			return
		}
		// 2. 超级管理员跳过权限检查
		if !isSuperAdmin(adminUser) {
			// 3. 检查接口权限
			if err := checkPermission(c, adminUser); err != nil {
				if businessErr, ok := err.(*e.BusinessError); ok {
					response.Fail(c, businessErr.GetCode(), businessErr.GetMessage())
				} else {
					response.Fail(c, e.ServerErr, "权限验证失败")
				}
				c.Abort()
				return
			}
		}
		c.Next()
	}
}

// checkPermission 检查接口权限
func checkPermission(c *gin.Context, adminUser *model.AdminUser) error {
	enforcer := casbinx.GetEnforcer()
	if enforcer.Error() != nil {
		log.Logger.Error("权限验证初始化失败", zap.Error(enforcer.Error()))
		return e.NewBusinessError(e.ServerErr, "权限验证初始化失败")
	}
	// 构建权限检查的 key
	userKey := fmt.Sprintf("%s%s%d", global.CasbinAdminUserPrefix, global.CasbinSeparator, adminUser.ID)
	path := c.Request.URL.Path
	method := c.Request.Method
	// 检查权限
	ok, err := enforcer.Enforce(userKey, path, method)
	if err != nil {
		log.Logger.Error("权限验证失败", zap.Error(err))
		return e.NewBusinessError(e.ServerErr, "权限验证失败")
	}
	// 如果没有权限，检查接口是否需要授权
	if !ok {
		if model.NewApi().CheckoutRouteIsAuth(path, method) {
			return e.NewBusinessError(e.AuthorizationErr, "暂无接口操作权限")
		}
	}
	return nil
}

这段逻辑里，真正要盯住的是两件事：用户身份是不是完整，权限判断是不是落到 Casbin 上。超级管理员直接放行，这种处理很常见，也省掉不少策略噪音。

策略是怎么存的

用 gorm-adapter 后，策略会进 casbin_rule 表：

CREATE TABLE `casbin_rule` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `ptype` varchar(100) DEFAULT NULL COMMENT '策略类型：p(策略) 或 g(角色继承)',
  `v0` varchar(100) DEFAULT NULL COMMENT '主体（subject）',
  `v1` varchar(100) DEFAULT NULL COMMENT '对象（object）',
  `v2` varchar(100) DEFAULT NULL COMMENT '操作（action）',
  `v3` varchar(100) DEFAULT NULL,
  `v4` varchar(100) DEFAULT NULL,
  `v5` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_casbin_rule` (`ptype`,`v0`,`v1`,`v2`,`v3`,`v4`,`v5`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;

ptype 区分策略类型，p 是权限本身，g 是继承关系。Casbin 的好处就在这里：它不会强迫你把'角色'和'资源'揉成一个难维护的表结构。

P 策略

格式是 [p, subject, object, action]。

例子：

• [p, menu:1, /api/v1/user/list, GET] - 菜单 1 可以访问 /api/v1/user/list 的 GET 方法
• [p, role:1, /api/v1/user/*, *] - 角色 1 可以访问所有 /api/v1/user/* 路径的所有方法

G 策略

格式是 [g, user, role]。

例子：

• [g, adminUser:1, role:1] - 用户 1 继承角色 1 的所有权限
• [g, role:1, menu:1] - 角色 1 继承菜单 1 的所有权限
• [g, dept:1, role:1] - 部门 1 继承角色 1 的所有权限

编辑权限和角色继承

项目里把'改权限'和'改角色'拆成了两个方法，处理方式都比较直接：先删旧的，再批量加新的。这个做法不花哨，但对后台管理足够稳。

// EditPolicyPermissions 编辑策略权限
// 策略格式：[p, 菜单 ID, 接口路径, 接口方法]
func (e *CasbinEnforcer) EditPolicyPermissions(user string, policy [][]string) error {
	return e.WithTransaction(func(enforcer casbin.IEnforcer) error {
		// 1. 删除用户的所有权限
		_, err := enforcer.DeletePermissionsForUser(user)
		if err != nil {
			return err
		}
		if len(policy) == 0 {
			return nil
		}
		// 2. 构建完整的策略规则
		var policies [][]string
		for _, p := range policy {
			if len(p) > 0 {
				// 策略格式：[user, route, method]
				policies = append(policies, append([]string{user}, p...))
			}
		}
		// 3. 批量添加所有策略
		ok, err := enforcer.AddPolicies(policies)
		if err != nil {
			return err
		}
		if !ok {
			return errors.New("添加权限失败")
		}
		return nil
	})
}

// EditPolicyRoles 编辑策略角色
// 策略格式：[g, user, role]
func (e *CasbinEnforcer) EditPolicyRoles(user string, policy []string) error {
	return e.WithTransaction(func(enforcer casbin.IEnforcer) error {
		// 1. 删除用户的所有角色
		_, err := enforcer.DeleteRolesForUser(user)
		if err != nil {
			return err
		}
		if len(policy) == 0 {
			return nil
		}
		// 2. 构建完整的角色继承规则
		var rules [][]string
		for _, role := range policy {
			if role != "" {
				// 策略格式：[user, role]
				rules = append(rules, []string{user, role})
			}
		}
		// 3. 批量添加所有角色继承关系
		ok, err := enforcer.AddGroupingPolicies(rules)
		if err != nil {
			return err
		}
		if !ok {
			return errors.New("添加权限失败")
		}
		return nil
	})
}

业务里怎么接

菜单权限

菜单和 API 绑定后，更新菜单权限其实就是更新一组 Casbin 策略。

// internal/service/permission/menu.go
// UpdateMenuPermissions 更新菜单权限
func (s *MenuService) UpdateMenuPermissions(menu *model.Menu, apiList []uint, tx ...*gorm.DB) error {
	// 1. 查询 API 信息
	apis := model.List(model.NewApi(), "id IN ?", []any{apiList}, model.ListOptionalParams{
		SelectFields: []string{"id", "route", "method"},
	})
	// 2. 构建策略规则
	policy := lo.Map(apis, func(api *model.Api, _ int) []string {
		return []string{api.Route, api.Method}
	})
	// 3. 更新 Casbin 策略
	menuName := fmt.Sprintf("%s%s%d", global.CasbinMenuPrefix, global.CasbinSeparator, menu.ID)
	enforcer := casbinx.GetEnforcer()
	if len(tx) > 0 {
		enforcer.SetDB(tx[0])
	}
	return enforcer.EditPolicyPermissions(menuName, policy)
}

用户角色分配

给用户分配角色，本质上是在改 g 策略。

// internal/service/permission/admin_user.go
// EditUserRoles 编辑用户角色
func (s *AdminUserService) EditUserRoles(uid uint, roleIds []uint, tx ...*gorm.DB) error {
	// 1. 构建角色标识列表
	roleList := lo.Map(roleIds, func(roleId uint, _ int) string {
		return fmt.Sprintf("%s%s%d", global.CasbinRolePrefix, global.CasbinSeparator, roleId)
	})
	// 2. 更新角色继承关系
	userName := fmt.Sprintf("%s%s%d", global.CasbinAdminUserPrefix, global.CasbinSeparator, uid)
	enforcer := casbinx.GetEnforcer()
	if len(tx) > 0 {
		enforcer.SetDB(tx[0])
	}
	return enforcer.EditPolicyRoles(userName, roleList)
}

角色权限管理

角色继承菜单权限，或者继续继承别的角色，逻辑也是同一套。

// internal/service/permission/role.go
// EditRoleMenus 编辑角色菜单
func (s *RoleService) EditRoleMenus(roleId uint, menuIds []uint, tx ...*gorm.DB) error {
	// 1. 构建菜单标识列表
	menuList := lo.Map(menuIds, func(menuId uint, _ int) string {
		return fmt.Sprintf("%s%s%d", global.CasbinMenuPrefix, global.CasbinSeparator, menuId)
	})
	// 2. 更新角色继承关系
	roleName := fmt.Sprintf("%s%s%d", global.CasbinRolePrefix, global.CasbinSeparator, roleId)
	enforcer := casbinx.GetEnforcer()
	if len(tx) > 0 {
		enforcer.SetDB(tx[0])
	}
	return enforcer.EditPolicyRoles(roleName, menuList)
}

事务里处理权限更新

权限更新最好跟业务数据放在同一个事务里，不然很容易出现'数据改了，权限没改'或者反过来的脏状态。这里的实现是把 Casbin 的 adapter 切到当前事务上，做完再恢复。

// WithTransaction 执行事务中的操作
func (e *CasbinEnforcer) WithTransaction(fc func(e casbin.IEnforcer) error) (err error) {
	a, ok := e.GetAdapter().(*gormadapter.Adapter)
	if !ok {
		return errors.New("适配器类型错误")
	}
	if e.tx != nil {
		if !isInTransaction(e.tx) {
			return errors.New("请先通过 GORM 开启事务后传入 SetDB")
		}
		defer func() {
			// 操作完成后，重置适配器
			e.SetAdapter(a.Copy())
			e.tx = nil
		}()
		// 创建事务适配器
		gormadapter.TurnOffAutoMigrate(e.tx)
		txAdapter, err := gormadapter.NewAdapterByDB(e.tx)
		if err != nil {
			return err
		}
		e.SetAdapter(txAdapter)
	}
	err = fc(e.Enforcer)
	return
}

使用时一般是这样：

// 在 GORM 事务中使用 Casbin
db.Transaction(func(tx *gorm.DB) error {
	// 1. 设置事务
	enforcer := casbinx.GetEnforcer().SetDB(tx)
	// 2. 更新业务数据
	// ... 业务逻辑 ...
	// 3. 更新权限策略（在事务中）
	menuName := fmt.Sprintf("menu:%d", menuId)
	return enforcer.EditPolicyPermissions(menuName, policy)
})

策略更新后要重新加载

EnableAutoSave(true) 只负责写库，不会自动把内存里的策略刷新掉。这个坑挺常见，尤其是你刚改完权限就马上测，很容易以为'没生效'。

// 重新加载策略
enforcer := casbinx.GetEnforcer()
if err := enforcer.LoadPolicy(); err != nil {
	log.Logger.Error("重新加载策略失败", zap.Error(err))
}

统一权限标识

项目里把用户、角色、菜单、部门都约定成统一前缀，读起来会清楚很多，也方便后面批量处理。

// internal/global/auth.go
const (
	CasbinAdminUserPrefix = "adminUser" // 用户前缀
	CasbinRolePrefix      = "role"      // 角色前缀
	CasbinMenuPrefix      = "menu"      // 菜单前缀
	CasbinDeptPrefix      = "dept"      // 部门前缀
	CasbinSeparator       = ":"         // 分隔符
)

对应格式就是：

• 用户：adminUser:1
• 角色：role:1
• 菜单：menu:1
• 部门：dept:1

常见问题

更新后权限没变

一般是策略写进库了，但内存里的 Enforcer 还在用旧数据。处理方式就是在更新后手动 LoadPolicy()。

enforcer := casbinx.GetEnforcer()
// 更新策略
enforcer.EditPolicyPermissions(userName, policy)
// 重新加载策略
enforcer.LoadPolicy()

事务回滚后权限状态不对

如果你在事务里改了策略，回滚后也要让内存状态回到数据库当前状态。最稳的办法还是在事务结束后重新加载。

db.Transaction(func(tx *gorm.DB) error {
	enforcer := casbinx.GetEnforcer().SetDB(tx)
	// 更新策略
	return enforcer.EditPolicyPermissions(userName, policy)
})
// 事务提交或回滚后，重新加载策略
enforcer := casbinx.GetEnforcer()
enforcer.LoadPolicy()

路径匹配不符合预期

keyMatch3 不是万能的，但对大多数后台路由够用。/api/v1/user/* 可以覆盖列表、详情这类接口；如果你的路径规则更细，就换成 keyMatch 或 regexMatch。

我会怎么用这套方案

这套实现最实用的地方，不是 Casbin 本身，而是它把后台里最烦的那部分收住了：用户、角色、菜单、接口之间的关系，不需要靠一堆手写 if/else 拼起来。权限更新走事务，策略存库，查询走内存，整体已经比较顺手。

当然，它也不是拿来就完美。真正要留心的是策略刷新和事务边界，别让'改了但没生效'这种问题混进去。把这两点处理好，RBAC 基本就能在 Go 管理后台里稳定跑起来。