权限变更必须事务包裹+审计写入+缓存失效三步闭环，缺一不可；日志须含UserIP、OperatorUserID、TargetUserID、Before、After、Status六要素，且实时清理Redis缓存确保权限即时生效。
权限变更不是“改个字段就完事”，而是要能回溯谁在什么时间改了谁的哪个角色、哪些权限，且变更必须原子生效、不可绕过日志。Gin 本身不提供权限变更逻辑，你得自己写事务包裹 + 审计写入 + 缓存失效三步闭环。
权限变更必须走事务，不能只更新 role_id
单纯执行 db.Model(&user).Update("role_id", newRoleID) 是危险的：如果后续审计日志写入失败，权限已变但无迹可查；若中间穿插并发读，可能读到半旧半新状态。
- 用
db.Transaction()包裹全部操作：角色变更、权限重载、审计记录写入、Redis 缓存user:123:perms删除 - 变更前先查旧值：
db.First(&oldUser, userID)，用于审计比对 - 禁止在事务内调用 HTTP 请求或耗时 IO（如发邮件），否则拖垮整个事务
- 事务失败时，确保所有 side effect（如 Kafka 消息、缓存清理）也回滚或补偿，不要只依赖数据库 rollback
变更审计日志字段必须含六要素，缺一不可
等保和 ISO27001 要求权限变更日志能回答六个问题：谁改的、改给谁、改了什么、何时改、从哪改（IP）、结果如何。少一个字段，审计就可能被判定为无效。
-
UserIP必须取自c.Request.Header.Get("X-Forwarded-For")或c.ClientIP()，不是c.Request.RemoteAddr -
TargetUserID和OperatorUserID要区分清楚——管理员 A 修改用户 B 的角色，两者 ID 都得记 -
Before和After字段建议存 JSON 字符串：{"role_id": 5, "permissions": ["user:read", "dept:list"]}，而非仅记录变更字段名 -
Status用 HTTP 状态码（如 200）或自定义 code（如 "success", "no_permission", "db_deadlock"），不能只写 "ok" - 日志必须异步写入独立文件（如
/var/log/app/perm-change.log），不能混进业务日志
权限实时生效需同步清理缓存，不能靠 JWT 过期硬等
JWT 里存的权限是快照，改完数据库后若不主动踢掉老 token 或清缓存，用户下次请求仍会按旧权限放行——这在敏感操作（如财务审批权变更）中不可接受。
立即学习“go语言免费学习笔记（深入）”；
- 变更后立即执行
redis.Del(ctx, "user:"+strconv.Itoa(userID)+":perms")，而不是等 token 自然过期 - 若用 Casbin，调用
enforcer.InvalidateCache()或手动enforcer.LoadPolicy() - 避免用 “全量刷新所有用户权限” 这种暴力方案：高并发下 Redis 压力大，且易引发缓存雪崩
- 前端登出按钮点击后，服务端应调用
jwt-auth的BlacklistToken()，而非仅删前端 localStorage
角色与权限解耦设计：别把 permission 字段塞进 role 表
很多团队把权限字符串（如 "user:read,user:write,dept:delete"）直接存在 role.permission 字段里，这会导致：无法按权限查角色、无法做权限继承、变更粒度粗、SQL 查询难优化。
- 必须拆成三张表：
roles、permissions、role_permissions（关联表） - 权限标识用层级命名：
hr:salary:view、hr:salary:edit:own、hr:salary:edit:all，方便策略匹配 - 角色可继承：在
role_permissions表加is_inherited bool字段，支持 “总监角色自动继承经理权限” - 前端菜单权限校验不要只看
role_id，而要用CanAccess("/api/v1/salary", "hr:salary:view")动态判断
权限变更系统最常被忽略的点，是“谁有权变更谁”的控制粒度——超管能改一切，HR 只能改本部门员工角色，但这个“本部门”约束必须在事务开始前就校验，不能靠事后审计补救。
