Go应用RBAC需同时实现应用内权限校验与K8s ServiceAccount+RoleBinding配置：前者须在HTTP中间件前置校验JWT并拒绝默认放行，后者缺一导致403或panic。
Go 应用本身不带 RBAC 部署能力，所谓“用 RBAC 部署”其实是两件事混说：一是应用内实现 RBAC 权限校验逻辑，二是 Kubernetes 集群中为该应用配置 ServiceAccount + RoleBinding。两者都漏不得，否则不是 403 就是 panic。
Go 应用内 RBAC 权限校验必须前置到 HTTP 中间件
权限检查不能放在 handler 里查完 DB 再判断——请求已进业务层，可能已发 MQ、写日志、甚至扣款。必须在中间件里完成身份解析 + 权限判定 + 拒绝拦截。
- 从
r.Context().Value("userID")取用户标识，来源只能是已校验的 JWT payload（检查exp、iss、aud），不能信Cookie或Header传的 raw ID - 权限检查函数签名统一用
func(resource string, action string) bool，比如rbac.HasPermission("article", "publish")，别用中文或模糊字符串如"can_edit_post" - 拒绝默认放行：没在策略里显式允许的
resource+action组合，一律返回http.StatusForbidden，不 fallback 到其他角色或兜底逻辑 - 预加载权限码到内存 map：
map[string]struct{}，key 就是"article:publish"这种扁平 code，避免每次查 DB 或遍历 slice
K8s 部署时 ServiceAccount 和 RoleBinding 缺一不可
本地跑通但上线报 User "system:serviceaccount:default:my-app" cannot list resource "pods"，这不是 Go 代码问题，是 K8s RBAC 没配。Pod 内用 rest.InClusterConfig() 拿的是挂载的 SA token，和本地 kubeconfig 完全无关。
- 先创建
ServiceAccount（如my-app-sa），再在 Deployment 的spec.serviceAccountName显式指定它 -
Role（命名空间级）或ClusterRole（集群级）定义能操作哪些资源和动作，例如允许get/list/watchconfigmaps -
RoleBinding把Role绑给ServiceAccount，注意subjects里kind必须写ServiceAccount，name写 SA 名，namespace写对命名空间 - 别漏掉
apiGroups字段：访问 core 资源（如pods）填""，访问apps/v1类资源必须显式列出
用 Casbin 时 Enforce 参数顺序和策略加载最容易出错
Casbin 的 enforcer.Enforce() 看似简单，但参数错一位、策略没加载、路径带 query string，都会静默返回 false。
-
Enforce严格按顺序接收三个string：用户 ID（不是对象）、资源路径（如/api/v1/users）、动作（如GET），多传、少传、类型不对都 panic 或返回 false - 策略必须动态加载：用
gorm-adapter时，确保enforcer.LoadPolicy()在用户登录后、鉴权前调用；用 file-adapter 则要确认rbac_model.conf路径正确且被挂载进容器 - 资源路径匹配要干净：策略里写
/api/v1/users，但请求是/api/v1/users?id=123，就匹配不上。建议中间件提前截掉 query string，或用keyMatch2模型支持通配 - 全局复用一个
enforcer实例，它本身线程安全；别在每个请求里casbin.NewEnforcer()，性能崩、内存涨
真正容易被忽略的是权限变更的热生效和数据级拦截——角色权限改了，前端菜单可能立刻刷新，但后端 API 的 Enforce 结果未必同步；更隐蔽的是，RBAC 只管接口维度，对 SELECT * FROM orders WHERE user_id = ? 这类数据级访问，必须在 DAO 层手动加 where 条件，否则越权读取照常发生。
