不能直接比较角色名，因为权限控制依赖角色关联的权限节点而非角色名称本身；需通过“用户→角色→权限节点”三级映射，登录后一次性加载并缓存权限节点，再用checkPermission()函数复用校验。
PHP 中用数组模拟 RBAC 权限判断，为什么不能直接比较角色名？
因为角色名只是标识，真正决定能否访问的是该角色被赋予的「权限节点」。比如 admin 角色可能有 user:delete 和 order:read，但没给 config:write；而 editor 角色反而有后者。硬编码角色名做 if 判断会迅速失控。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 权限校验必须基于「用户 → 角色 → 权限节点」三级映射，不是用户 → 角色 → 硬编码规则
- 把权限节点设计成冒号分隔的字符串（如
post:publish、comment:ban），便于按模块/操作归类 - 避免用数据库每次查权限：登录后把用户所有有效权限节点一次性查出，存进
$_SESSION['permissions']或 Redis 缓存，后续用in_array()判断
如何用 PHP 实现一次查库、多次复用的权限检查函数？
核心是分离「加载权限」和「校验权限」两个动作。不要在每个接口里都查数据库，也不要写一堆重复的 if (in_array(...))。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 封装一个
checkPermission($node)函数，在内部自动读取$_SESSION['permissions']（或从缓存取），不存在则触发一次loadUserPermissions($uid) -
loadUserPermissions()要 JOIN 三张表：users→role_user→permission_role→permissions，SELECT 出所有node字段值 - 权限节点区分大小写，且建议统一小写存储和校验，避免
Post:Publish和post:publish被当成两个权限
function checkPermission($node) {
if (!isset($_SESSION['permissions'])) {
$_SESSION['permissions'] = loadUserPermissions($_SESSION['uid']);
}
return in_array($node, $_SESSION['permissions']);
}RBAC 的「继承」和「拒绝」怎么处理？PHP 数组方案下容易踩哪些坑？
纯数组方案不支持动态继承或显式拒绝（deny），强行加逻辑会让判断变复杂、难维护。比如「管理员默认拥有全部权限，但禁止删除自己账号」这种需求，靠数组 + if 很难干净表达。
TURF（开源）权限定制管理系统（以下简称“TURF系统”），是蓝水工作室推出的一套基于软件边界设计理念研发的具有可定制性的权限管理系统。TURF系统充分考虑了易用性，将配置、设定等操作进行了图形化设计，完全在web界面实现，程序员只需在所要控制的程序中简单调用一个函数，即可实现严格的程序权限管控，管控力度除可达到文件级别外，还可达到代码级别，即可精确控制到
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 放弃在数组层实现「拒绝」：把
user:self-delete单独设为一个权限节点，不赋给任何人，需要时再显式授予——而不是在已有权限上打补丁 - 角色继承（如
editor继承viewer）不要靠 PHP 数组 merge，而是在数据库里用role_inherit表记录，loadUserPermissions()查询时递归展开 - 别把权限校验写进模板层（如 view.php 里直接调
checkPermission()），应前置到控制器或中间件，避免页面渲染一半才发现没权限
为什么用 strpos() 做模糊权限匹配很危险？
有人想支持「前缀通配」，比如给角色赋了 user:，就认为能访问 user:create、user:delete。但 strpos($node, 'user:') 会错误放行 user_profile:edit 或 superuser:reset。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 真要前缀控制，用
strncmp($node, 'user:', 5) === 0，且确保$node长度 ≥ 5 - 更稳妥的做法是明确声明子权限：定义
user:*作为一个独立节点，校验时特殊处理，而不是靠字符串匹配猜意图 - 生产环境禁用任何通配逻辑，所有权限节点必须精确匹配，否则审计和排查时根本不知道谁被放过了
权限系统最易被忽略的点是「权限变更后缓存未失效」。用户刚被授予权限，刷新页面还是 403，问题往往不在校验逻辑，而在 $_SESSION['permissions'] 没清，或 Redis 缓存 TTL 设得太长。每次修改角色权限后，记得主动清理对应用户的权限缓存。
