权限数据应采用RBAC模式的三表结构（auth_rule、auth_role、auth_role_access）支持动态分配，其中auth_rule需含status字段，关联表auth_role_access是动态增删权限的核心，用户表通过role_id或JSON字段关联角色。
权限数据怎么存才支持动态分配
动态权限分配的前提是权限结构能灵活增删改，不能硬编码在代码里。ThinkPHP 本身不强制权限存储格式，但实际项目中，rbac 模式（角色-权限-用户）最常用也最可控。关键不是用不用 RBAC，而是表结构是否支持运行时变更：
-
auth_rule表存权限节点（如admin/article/edit、user/profile/update），必须带status字段控制启用/禁用 -
auth_role表存角色（如 “编辑”、“审核员”），不绑定具体权限，只作分组标识 -
auth_role_access表做角色与规则的中间关联，这是动态分配的核心——增删这条记录就等于给角色加/减权限 - 用户表里只需一个
role_id或role_ids（支持多角色时建议 JSON 字段或中间表）
别把权限写成常量或配置文件，否则每次改权限都要改代码、发版、清缓存——这不是动态，是伪动态。
AuthRule::check() 调用时机和参数陷阱
ThinkPHP 自带的 AuthRule::check() 是校验入口，但它默认只认当前控制器/方法名拼接（如 Index/index），而真实业务里权限标识往往更细：比如“仅允许编辑自己发布的文章”，这时光靠路由节点不够，得结合数据上下文。
- 调用前必须确保已登录且用户角色信息已加载，否则
check()返回false不代表没权限，可能是用户未认证 - 第二个参数默认是
session('user.id')，但如果你用的是多角色，得手动传入角色 ID 列表，例如：AuthRule::check('article/delete', [1, 5]) - 权限标识字符串要和
auth_rule表里的name完全一致，大小写、斜杠方向、末尾斜杠都不能错——admin/article/delete/和admin/article/delete是两条不同规则 - 别在模型层或命令行任务里直接调用
check()，Session 在 CLI 下不可用，需换为基于user_id的无状态校验方式
如何绕过 AuthRule 实现字段级权限控制
菜单、按钮可见性属于路由/操作级权限，但真正敏感的是字段——比如财务系统里，“实发工资”字段只对 HRBP 可见，其他人看到的是脱敏后的 ****。这种没法靠 AuthRule::check() 解决，得在数据组装阶段干预。
立即学习“PHP免费学习笔记（深入）”；
- 在查询后、返回前做字段过滤：用
array_diff_key()剔除用户无权访问的键，例如从$data中移除['salary_real', 'id_card'] - 不要在模板里用
if判断权限再输出字段——HTML 源码里仍可能残留敏感字段，必须服务端过滤 - 如果用 ORM 查询，可在
append属性或getAttr方法里嵌入权限判断，例如getSalaryRealAttr内部先查AuthRule::check('user/salary/view')再决定返回值 - 注意 API 接口返回的 JSON 也要走同一套过滤逻辑，别只顾后台页面
缓存失效导致权限更新不生效怎么办
ThinkPHP 默认会把权限规则缓存到 runtime/cache/ 下，提升校验性能。但这也意味着你改了 auth_rule 表，前端还是旧权限——不是代码有问题，是缓存没炸干净。
- 开发期建议关闭权限缓存：在
config/auth.php中设'cache' => false，上线后再打开 - 生产环境更新权限后，必须主动清除
auth_rule相关缓存，推荐方式是执行php think clear --cache，或调用Cache::clear('auth_rule') - 如果用了 Redis 做缓存驱动，确认缓存 key 命名是否含环境标识（如
prod_auth_rule），避免测试服清缓存影响线上 - 更稳妥的做法是在
auth_role_access表加update_time字段，每次分配权限后更新该时间戳，并在缓存读取逻辑里加入版本比对
细粒度权限真正的复杂点不在怎么写，而在什么时候清缓存、谁来触发刷新、以及前端拿到的权限列表是否和服务端实时一致——这些环节断一环，动态就变成静态。
