Go中RBAC落地需手动建模User/Role/Permission/Resource四者关系，采用轻量结构体+接口+中间件，通过工厂函数绑定权限规则，结构化存储权限字段并加联合索引，数据级权限在repository层结合上下文过滤。
RBAC模型在Go Web中怎么落地
Go里没有开箱即用的RBAC框架，得靠自己组合：用户（User）、角色（Role）、权限（Permission）、资源（Resource）四者关系要手动建模。别直接抄Python或Java的RBAC库设计——Go的惯用法是轻量结构体 + 接口抽象 + 中间件拦截。
典型做法是定义一个 CheckPermission 函数，接收 userID、resource（如 "article"）、action（如 "delete"），返回布尔值。背后查数据库或缓存，走的是「用户→角色→权限」三级关联查询。
- 避免把角色硬编码进HTTP handler，否则改个权限就得改代码
- 资源名建议统一小写+中划线（
"user-profile"），别用驼峰，方便路由匹配和策略表达 - 如果用GORM，
Role和Permission之间推荐用多对多中间表（role_permissions），别用JSON字段存权限列表——没法索引、难审计、不支持动态增删
gin/echo等框架里怎么加权限中间件
以 gin 为例，权限中间件本质就是检查 c.Get("user_id") 是否有当前路由所需的权限。关键不是“怎么写中间件”，而是“权限元信息从哪来”。常见错误是把 resource/action 写死在中间件里，导致每个接口都要配一次中间件实例。
更可行的方式是：在路由注册时就绑定权限规则。比如：
立即学习“go语言免费学习笔记（深入）”；
r.DELETE("/articles/:id", permissionMiddleware("article", "delete"), deleteArticleHandler)
其中 permissionMiddleware 是个工厂函数，返回闭包中间件。它把 "article" 和 "delete" 带进去了，handler里不用再判断。
- 别在中间件里重复查DB——查一次，塞进
c.Set("permissions", perms)，后续逻辑可复用 - 如果用JWT，权限可以预存在token的
perms字段里，但要注意过期同步问题；敏感操作（如删库）仍需服务端二次校验 - 403响应不要暴露细节，统一返回
http.Error(c.Writer, "Forbidden", http.StatusForbidden)，别写“缺少 article:delete 权限”
数据库表设计要注意哪些坑
最常翻车的是把 Permission 设计成字符串枚举（如 "user:read"），看着灵活，实际导致SQL难写、索引失效、拼写错误难发现。应该拆成结构化字段：
-
permissions表：含resource（VARCHAR）、action（VARCHAR）、scope（ENUM('own', 'team', 'all')，用于区分“只能删自己的文章”还是“能删所有”） - 加联合唯一索引：
(resource, action, scope)，避免重复权限 -
user_roles和role_permissions都要加ON DELETE CASCADE，否则删角色后权限残留 - 别给
User表加role_id字段——用户可能有多个角色，必须走中间表
如何支持“数据级权限”（比如只看自己部门的数据）
RBAC本身只管“能不能访问某类资源”，不管“能访问哪些具体数据”。这部分得结合业务逻辑做二次过滤，不能全丢给中间件。
例如用户请求 GET /articles，权限中间件只确认他有 "article:list"，但实际查库时得加 WHERE department_id = ? 或 WHERE author_id = ?。推荐方式是在repository层注入上下文：
func (r *ArticleRepo) List(ctx context.Context, opts ListOptions) ([]Article, error) {
userID := auth.UserIDFromCtx(ctx)
deptID := auth.DeptIDFromCtx(ctx) // 从token或session提取
return r.db.Where("department_id = ?", deptID).Find(&articles).Error
}
- 别在handler里拼WHERE条件——容易漏、难测试、违反关注点分离
- 如果用GORM，可封装
ScopedQuery方法，自动根据ctx注入租户/部门/用户ID过滤条件 - 特别注意分页场景：count查询也得带同样过滤条件，否则前端分页数会错
真正麻烦的不是模型设计，而是权限变更后的实时生效——比如管理员刚收回某人权限，他还能凭旧token继续操作几分钟。这需要结合token黑名单或短生命周期（≤15分钟）+ 强制刷新机制，而不是指望RBAC表一更新就立刻阻断请求。
