Go没有内置权限系统，也无开箱即用RBAC框架；需自建User→Role→Permission三层结构，权限校验前置HTTP中间件，K8s部署须配ServiceAccount的RoleBinding，规则支持热更新，数据级权限须在DB层拦截。
怎么定义 Role/Permission 结构才不翻车
别用 if user.Role == "admin" 这种字符串比较，它无法扩展、不能审计、一加新权限就得改代码。真实项目里要用数据库三张表建模：
-
roles表：只存id、name（如"editor"），加唯一索引 -
permissions表：字段是code（如"post:update"）、description，code 必须小写+下划线，禁用空格和中文 -
role_permissions表：复合主键(role_id, permission_code)，不是permission_id——后期改code不用动外键
结构体就按表来：type Permission struct { Code string `json:"code"` }，别塞逻辑进 struct，那是 service 层的事。
Gin 中间件里怎么查权限才不拖垮 DB
常见错误是每次请求都走一遍 db.Where("role_id = ?", u.RoleID).Find(&perms)——QPS 上去 DB 直接 504。正确路径是「内存缓存 + DB 回源」：
- 启动时预热加载所有
role:xxx:permissions到map[string][]string，key 是角色名，value 是权限码切片（如["user:read", "post:list"]） - 中间件里从 context 取用户角色（
c.MustGet("user").(*User).Role），再查这个 map，O(1) 完事 - 如果角色会动态变（比如运营后台改权限），就换 Redis 缓存：
user:<id>:permissions</id>，过期设 15 分钟，DB 回源时加读锁防击穿 - 禁止在中间件里拼 SQL 或查具体数据行——它只管“能不能进”，不管“能看哪几条”
用 Casbin 还是手写？关键看这三点
Casbin 不是银弹，但它能帮你绕过通配符匹配、角色继承、策略热更新这些坑。是否引入，看团队实际需求：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 如果你的权限规则半年不变，且只有几十个接口，
map[string][]string预热加载 + Gin 中间件足够稳 - 如果你要支持多租户、路径前缀匹配（如
/api/v1/users/*）、运行时增删权限，选 Casbin +gorm-adapter，但必须：
– 全局复用一个*casbin.Enforcer实例
– 调用e.LoadPolicy()或e.AddNamedPolicy()后，确认日志输出loaded x policies
–Enforce()参数顺序必须是user, resource, action，传错顺序永远 false - 最常踩的坑：
resource传了带 query 的 URL（如/users?id=1），但策略里写的是/users，匹配失败——中间件里提前strings.Split(r.URL.Path, "?")[0]截掉 query
为什么本地 OK，上线 K8s 就 403？
这不是 Go 代码问题，而是 Kubernetes 的 ServiceAccount RBAC 没配。当你用 rest.InClusterConfig() 调 k8s API 时，用的是 Pod 内挂载的 token，身份是 system:serviceaccount:default:my-app，跟本地 kubeconfig 完全两套体系。
解决方法只有一条：kubectl create rolebinding my-app-viewer --clusterrole=view --serviceaccount=default:my-app -n default。漏掉这步，任何 Go 代码都 403。
真正难 debug 的地方不在权限逻辑本身，而在「缓存没刷新」「角色没绑定权限」「中间件注册顺序错位」「JWT 漏校验 exp」——这些点不打日志、不压测，上线后只能靠 403 日志反推。
