权限校验必须下沉到业务层，用checkPermission()实时判断菜单、字段、按钮等细粒度权限，中间件仅用于未登录等粗粒度拦截。
PHP 动态权限判断该用 checkPermission() 还是中间件？
直接说结论：权限校验逻辑必须下沉到业务层，不能只靠路由中间件兜底。中间件适合做粗粒度拦截（比如“未登录跳转”），但菜单显示、按钮灰显、API 返回字段过滤这些，都得在 PHP 里实时调用 checkPermission() 判断。
常见错误是把所有权限检查塞进 Laravel 的 can() 中间件或 ThinkPHP 的 Auth::check()，结果发现菜单不隐藏、接口返回了不该看的数据——因为中间件只管进不关出。
- 菜单渲染前必须调用
checkPermission('menu:dashboard')，返回false就跳过该项 - 控制器里查用户列表时，如果当前角色无权查看手机号，就得在
select字段里去掉phone，而不是查出来再 unset - 别依赖前端传来的
role_id或permission_code做判断，一律以当前登录用户的user_id查数据库或缓存中的权限快照
RBAC 表结构怎么设计才不踩坑？
最常崩的是“权限粒度太粗”和“关系表缺失时间戳”。比如只建 roles、permissions、role_has_permissions 三张表，上线后才发现没法回溯“谁在什么时候给某角色加了删除权限”。
真实项目要预留审计和灰度能力：
立即学习“PHP免费学习笔记（深入）”；
-
role_has_permissions表必须有created_by（操作人 ID）和created_at，否则运营说“昨天还没这按钮”，你查不到依据 - 权限码别用中文或长描述，统一用下划线小写格式，如
order:export、user:reset_password，避免空格、斜杠、大小写混用导致匹配失败 - 菜单表
menus要带permission_code字段，且允许为空（用于分组标题），别指望靠父级 ID 推导权限 - 别把“可见”和“可操作”绑死在一个权限码上，
menu:report控制左侧菜单是否显示，report:download单独控制导出按钮，否则后期改需求就绕不开改代码
Laravel / ThinkPHP 里怎么高效查权限？别每次都查库
用户每次请求都执行 3–5 次 JOIN 查询权限，QPS 上不去是必然的。缓存不是可选项，是必选项，但缓存策略错了反而更慢。
关键点在于：缓存键要包含 user_id + role_updated_at 时间戳，而不是简单用 user_id。
- ThinkPHP 示例：
cache('perm_' . $user_id . '_' . db('roles')->where('id', $roleId)->value('updated_at'))，角色权限一更新，对应缓存自动失效 - Laravel 不要用
Auth::user()->permissions这种 Eloquent 关系加载，改用原生查询一次性取出所有permission_code数组，然后in_array('post:delete', $perms) - 缓存过期时间设为 10 分钟足够，权限变更属于低频操作，没必要实时；但一定要监听角色/权限表的更新事件，主动删缓存，别等过期
- 如果用了 Redis，别把整个权限数组序列化成一个大 value，拆成
perm:{user_id}:codes和perm:{user_id}:menus两个 key，前端要菜单、后端要 API 权限时各取所需，不浪费网络和内存
前端传来的权限标识能信吗？
不能。任何从 $_GET、$_POST、请求头、甚至 localStorage 里读出来的 permission_code，都只能当参考，不能当判断依据。
典型翻车场景：前端根据用户角色渲染了“编辑按钮”，但用户手动改了 URL 参数或发了个带 permission=article:edit 的 POST 请求，后端没二次校验就执行了更新。
- 所有敏感操作入口（如
/api/articles/{id}的 PUT/PATCH/DELETE），必须在控制器里用当前auth()->id()重新查权限，不能信任请求里带的任何标识 - 菜单数据可以缓存并由前端渲染，但“提交”“删除”这类动作，必须走后端权限校验，且校验粒度要细到具体资源实例，比如
checkPermission('article:delete', ['article_id' => 123])，而不是只认article:delete - 别在 JS 里写
if (user.perm.includes('user:delete')) {...}然后直接发请求，这种写法等于把权限逻辑暴露给用户，抓个包就能伪造
权限系统真正难的不是建表或写函数，是时刻记住：用户身份可信，用户行为不可信；缓存可快，但不能快到绕过校验；前端展示可以松，后端执行必须严。
