ThinkPHP RBAC需手动建模与校验，核心是四张表（用户、角色、权限、两关联表），权限name唯一规范（如user:delete），含type/is_menu/sort/path/status字段；校验须在控制器/中间件主动触发，缓存权限白名单并及时更新；前后端需协同过滤菜单按钮，且后端必须二次校验。
ThinkPHP 的 RBAC 权限管理不是开箱即用的功能，它依赖开发者手动建模、显式校验和合理缓存。核心不在于框架有没有“权限类”，而在于你如何组织数据、映射路由、拦截请求并控制渲染逻辑。
权限表结构与字段设计
必须使用四张基础表：用户表（如 sys_user）、角色表（sys_role）、权限表（sys_permission）、以及两个关联表（sys_user_role 和 sys_role_permission）。不要把权限塞进用户字段里，否则无法索引、难审计、不支持动态变更。
- sys_permission 中的 name 字段是权限标识核心，必须唯一且规范，推荐用英文冒号分隔（如 user:delete 或 admin:article:publish），避免空格或中文
- 加 type 字段区分类型：menu 表示左侧导航项，api 或 action 表示接口或按钮操作
- 菜单类权限需额外字段：is_menu（tinyint）、sort（排序）、path（对应前端路由）
- 所有权限记录必须保留 status 字段，禁用时设为 0，而不是物理删除
权限校验的触发位置与方式
ThinkPHP 不会自动拦截未授权访问，你必须在关键节点主动检查。控制器方法入口、中间件、甚至模板渲染前，都要有明确的权限判定逻辑。
- 对后台页面，建议在基类控制器的 initialize() 方法中调用统一校验函数，失败则跳转 403 或返回提示
- 对 API 接口，应统一放在中间件中处理，比如 PermissionCheck，通过 request()->rule()->getName() 获取当前路由名，再转换为权限标识（如 admin/user/edit → admin.user.edit）
- 校验依据必须是“当前用户激活角色所拥有的全部权限 name 列表”，不能只查用户 ID 直连权限，否则角色调整后不会实时生效
- 每次请求都查库性能差，要用 Cache::get('permission_list_'.$uid) 缓存权限数组，注意在角色变更、权限更新、用户登出时清除对应缓存
前后端协同的权限落地细节
权限不只是后端拦住请求，还要让前端知道“能看什么、能点什么”，这需要前后端配合完成，且后端必须做二次防护。
立即学习“PHP免费学习笔记（深入）”；
- 登录成功后，后端应一次性返回该用户所有可访问的 permission_name 白名单（如 ['user:list', 'user:edit', 'menu:system']）
- 前端菜单栏根据 is_menu=1 的权限项 + 白名单过滤渲染；按钮显隐也靠白名单判断，不能仅靠角色名或用户类型
- 即使前端隐藏了按钮，对应接口仍必须在中间件或控制器中再次校验权限，防止绕过前端直接调用
- 权限 name 必须严格匹配路由定义。例如路由是 Route::get('admin/user/index', [...])，那权限名就只能是 admin/user/index，不是 admin.user.index 或 user_index
不复杂但容易忽略——RBAC 能跑通，靠的是数据结构清晰、校验点明确、缓存及时、前后端各守边界。
