ThinkPHP 6.x 的 RBAC 需手动建模实现，不依赖内置 Auth 类或权限中间件；核心是四张表（用户、角色、权限、关联表），权限 name 须用英文冒号分隔（如'user:delete'），校验需在控制器或中间件中显式调用并缓存权限列表，菜单与按钮显隐应基于后端返回的 permission_name 白名单过滤，且接口层必须二次校验确保安全。
ThinkPHP 6.x 的 RBAC 实现不依赖框架内置的“权限中间件”或“Auth 类”，它需要你手动建模、控制授权逻辑，并在关键节点（如控制器方法入口、菜单渲染、按钮显隐）主动校验。官方并未提供开箱即用的 RBAC 模块，所谓“ThinkPHP RBAC”本质是开发者基于其数据库抽象和请求生命周期自行组装的一套流程。
如何设计 ThinkPHP 的 RBAC 数据库表结构
ThinkPHP 本身不限定表名，但为后续逻辑清晰，建议采用标准 RBAC0 模型的四张表：用户表（sys_user）、角色表（sys_role）、权限表（sys_permission）、以及关联表（sys_role_permission 和 sys_user_role）。不要把权限直接存进用户表字段（比如 JSON 字段），否则无法走数据库索引、难以审计、也无法支持动态权限变更生效。
-
sys_permission表中必须包含name（如'user:delete'）、type（'menu' / 'api'）、path（对应路由或接口路径）三个核心字段 - 权限
name建议统一用英文冒号分隔的命名规范，避免空格或中文，方便代码中用in_array()或str_contains()快速匹配 - 如果要用菜单权限控制左侧导航栏显示，
sys_permission还需加is_menu（tinyint）和sort字段 - 不要省略
status字段——禁用某条权限时，仅设status=0即可，无需删数据，这对审计和灰度发布很重要
如何在 ThinkPHP 控制器中做权限校验
ThinkPHP 不会自动拦截未授权请求，你必须在每个需要保护的控制器方法里显式调用权限检查逻辑。最常用方式是封装一个 checkPermission() 方法，在 initialize() 或具体 action 中调用。
- 校验依据应是当前用户已激活的角色所关联的所有
sys_permission.name，而不是直接查用户 ID 对应的权限——角色继承或批量调整时，前者才可立即生效 - 不要在每次请求都重新查库，用
Cache::get('permission_list_'.$uid)缓存用户权限列表（注意缓存失效时机：角色变更、权限变更、用户登出） - 对 API 接口，推荐在中间件中统一处理；对后台页面，可在基类控制器的
initialize()中调用，失败则重定向到 403 页面或返回 JSON 错误 - 若使用路由分组（如
admin/下所有路由），可在分组绑定的中间件中统一校验前缀，例如判断'admin:user:index'是否在权限列表中
为什么 Auth::check() 不适合 ThinkPHP RBAC 场景
ThinkPHP 自带的 Auth 类是基于规则表达式的 ACL 模型，不是 RBAC。它把“用户-规则”直接映射，缺少角色这一中间层，导致权限调整必须逐个用户操作，无法批量赋权、无法做角色继承、也不支持权限复用。
立即学习“PHP免费学习笔记（深入）”；
-
Auth::check()的规则字段（auth_rule表的condition）写的是 PHP 表达式字符串，执行效率低且难调试，例如"$user['score'] > 100" - 它的
auth_group_access表只存用户与组（角色）关系，但没提供组与权限的多对多绑定能力，实际仍需额外开发 - 官方文档已明确标注该模块“适用于小型系统”，企业级 RBAC 必须绕过它，从零构建角色-权限链路
- 如果你已在用
Auth，迁移时重点改三处：停用AuthRule表、重建sys_role_permission关联逻辑、替换所有Auth::check()调用为自定义权限查询
菜单渲染和按钮显隐怎么同步权限状态
前端菜单不是靠后端“给什么就渲染什么”，而是后端返回完整菜单结构 + 权限标记，前端再按需过滤。否则会出现“菜单能点但点击 403”的体验断层。
- 后台接口（如
/api/menu）应返回全量菜单树，每项带permission_name字段（如'system:role:list'），前端用这个字段查当前用户权限列表是否包含它 - 按钮级控制（如“删除”按钮）不要靠 JS 判断 URL 或文字来隐藏，而应在接口返回的数据项中增加
actions字段，例如：{"edit": true, "delete": false} - ThinkPHP 模板中避免写
{if $auth->check('user:delete')}这类逻辑——它又回到了 ACL 思路，且模板层不该承担权限决策职责 - 真正安全的边界在后端接口：即使按钮没隐藏，点击后接口仍要再次校验权限，防止前端篡改
RBAC 在 ThinkPHP 中不是“配置一下就跑起来”的功能，它的复杂点在于权限变更的传播时效性（缓存刷新）、角色继承的实现深度（是否支持多级继承、互斥约束）、以及前端与后端权限语义的一致性。最容易被忽略的是：菜单接口返回的权限标识，和接口路由定义的权限标识，必须严格一致，一个字母都不能错。
