权限校验应统一收口到中间件，而非Controller或验证器；中间件中基于用户ID查缓存权限节点，避免DB查询；RBAC需支持角色继承，权限校验依据必须是节点字符串而非role_id。
权限校验该放在哪里？Controller 还是中间件？
直接放 Controller 方法里是最常见也最容易失控的做法——重复写 Auth::check()、硬编码角色名、漏掉某个接口，一上线就出权限绕过。真正稳的方案是统一收口到中间件，尤其是 ThinkPHP 6+ 的「闭包中间件」或「类中间件」。
自定义中间件能明确分离关注点：路由进来了，先过权限关，不满足直接 throw new HttpException(403) 或返回 JSON 错误，Controller 完全不用操心“我有没有权”。
- 中间件中调用
Auth::user()获取当前登录用户，再查其角色/权限节点（建议缓存user_permissions字段或 Redis 中的权限集合） - 避免在中间件里做 DB 查询，权限数据应提前加载好；若用 RBAC 模型，推荐预载
roles.permissions关系，而不是每次查三张表 - 别用
session('admin_role')这类弱校验——Session 可被伪造，必须以用户 ID 为依据重新查库或缓存
自定义验证器怎么接权限字段？rule 里不能写业务逻辑
ThinkPHP 的 Validate 类本质是数据格式与范围校验器，不是权限闸门。你不能在 rule 里塞 Auth::can('delete_user')——它没用户上下文，且校验器执行时机早于中间件，此时 Auth 可能根本没初始化。
真要结合权限做字段级控制（比如：普通管理员不能改 is_super 字段），得换思路：
- 在 Controller 接收数据前，先用
input()拿原始参数，手动过滤掉无权修改的键：array_filter($data, function($k) { return in_array($k, $allowedFields); }, ARRAY_FILTER_USE_KEY) - 或者用「场景验证」+ 动态规则：定义
scene('edit')，并在调用前根据当前用户权限动态设置$validate->scene('edit')->rule([...]) - 切记：验证器的
message里别暴露权限细节，比如不要写“你不是超级管理员”，统一返回“参数非法”
Auth::can() 返回 false 就一定没权限？小心缓存和节点路径写错
这个函数看似简单，但背后依赖两个关键前提：权限节点注册正确、用户权限缓存实时。一旦返回 false，90% 是配置问题，不是代码逻辑错。
典型翻车点：
- 节点标识符写成
'admin/user/delete'，但数据库里存的是'admin:user:delete'或少了个斜杠——ThinkPHP 默认用/分割，不匹配就查不到 - 用
Auth::setUser($user)手动设用户后，没清空旧权限缓存，导致can()仍读取上一个用户的权限结果 - 权限缓存用了
File驱动，在多服务器部署时不同机器缓存不一致；生产环境必须切到Redis或Memcached
调试时可临时加一行：dump(Auth::getPermissions()); 看当前用户实际加载了哪些节点，比猜快得多。
RBAC 权限表设计漏了「权限继承」会卡死后期迭代
很多团队初期只建 role、permission、role_permission 三张表，以为够用。等加了“区域管理员”“部门主管”“审计员”这些角色，发现每个都要重复绑几十个权限，改一个就得批量更新，立刻崩溃。
真正可维护的设计必须支持角色继承：
- 给
role表加个pid字段，指向父角色 ID；查权限时递归合并所有上级权限（注意防环） - 或引入
role_inherit中间表，显式声明child_id → parent_id关系，更清晰也更好查 - 别让前端传
role_id来判断权限——角色只是容器，真正校验依据必须是权限节点字符串，否则换角色策略就全乱
权限系统最难的从来不是写代码，而是把“谁能在哪干啥”这件事，用数据库里几行记录说清楚。字段少一个，后期补成本翻倍。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
