应在路由层绑定权限标识并由中间件统一拦截，登录后缓存权限至session/redis，ajax请求返回json错误，rbac表需含type、scope、expires_at字段支撑细粒度控制。
如何在路由层声明并拦截无权限的敏感操作
ThinkPHP8 的权限检查不能只靠控制器里 if (!in_array('delete_user', $user->permissions)) 这种硬编码判断——它既难维护，又绕过中间件生命周期，还容易漏掉 AJAX 请求或命令行调用。真正有效的做法是把权限标识绑定到路由上，由中间件统一拦截。
- 在定义路由时直接传入权限标识：
Route::get('admin/user/delete/:id', 'Admin/User.delete')->middleware('permission:delete_user') - 中间件中通过
$request->route()->rule()或自定义路由属性获取该标识，而不是从 URL 路径里拼接解析（易被绕过） - 注意：
permission中间件必须注册为全局中间件或至少作用于admin组路由，否则对未显式调用的子路由无效 - 超级管理员（如
authId === 'admin'）应跳过所有检查，但这个逻辑必须放在中间件最前，避免先查数据库再绕过，造成性能浪费
为什么 getAllPermissions() 不能每次请求都查库
用户模型里写个 getAllPermissions() 方法看似干净，但如果每次请求都走一遍 $user->roles->permissions 关联查询，5 层嵌套 JOIN 加缓存缺失，单次权限校验可能触发 3+ 次数据库查询——高并发下 DB 直接排队。
- 正确做法是登录后一次性查出全部权限名，存入 Session 或 Redis，键名为
user_permissions_{uid}，有效期设为 1 小时 - 中间件里优先读
Session::get('user_permissions')，为空才 fallback 到数据库，并立即回填 - 权限变更时（如后台改角色），必须主动删除对应
user_permissions_{uid}缓存，否则出现“已删权限但还能操作”的经典脏数据问题 - 别用 ThinkPHP 的
Cache::tag()自动清理——RBAC 场景下 tag 太宽泛，容易误删其他业务缓存
PermissionCheck 中间件里如何区分 AJAX 和页面请求
用户点一个删除按钮，前端可能是 fetch('/admin/user/123', {method: 'DELETE'})，也可能是表单提交跳转；服务端若统一返回 403 页面，AJAX 请求就卡死在控制台，而页面请求却能显示友好提示——这会让前端同学反复问“为啥我 status=403 但没弹框？”
- 用
$request->isAjax()判断请求类型，但注意：某些代理或前端框架可能不带X-Requested-With头，需配合$request->header('accept') === 'application/json'双重校验 - AJAX 请求应返回 JSON：
return Response::create(['code'=>403, 'msg'=>'无操作权限'], 'json')->code(403) - 普通请求可重定向到 403 页面：
return redirect('@403')，前提是该模板存在且不依赖权限变量 - 千万别在中间件里 echo 或 exit —— ThinkPHP8 的中间件管道机制会中断后续处理，导致日志、钩子等失效
RBAC 表结构设计最容易忽略的三个字段
很多项目照搬旧版 ThinkPHP 的 sp_node 表，只存 module/action 字符串，结果遇到“同一接口不同参数需不同权限”（比如只允许删自己发布的文章）就卡住——这不是代码问题，是模型设计缺位。
- 权限表（
permission）必须有type字段：'route'（路由级）、'button'（按钮级）、'data'（数据级），否则无法支撑细粒度策略 - 角色-权限中间表（
role_permission）要加scope字段，支持按组织、租户、客户 ID 隔离权限，不然 SaaS 多租户场景直接崩 - 用户-角色中间表（
user_role）得有expires_at时间戳，临时权限（如审计员仅限今日访问）才能可控失效，而不是靠删记录来回滚
权限不是越细越好，但表结构一旦定死，后期加字段要改迁移、补数据、修所有关联查询——上线前多花 20 分钟想清楚这三个字段，比上线后通宵修 ABAC 规则强得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
