php权限管理核心是角色+资源+动作三元组控制，用session存role_id、db实时校验权限、集中式can()函数、路由层前置拦截、白名单约束参数、缓存设ttl并主动失效、禁止模板层权限控制、行级权限需业务逻辑显式处理。
PHP 实现简单权限管理，核心不是堆功能，而是明确「谁能在什么上下文中执行什么操作」——用角色+资源+动作三元组控制，不引入框架也能跑得稳。
用 session 存角色 ID 而不是角色名或权限列表
直接存 $_SESSION['role_id']，而不是 $_SESSION['role'] = 'admin' 或更糟的 $_SESSION['permissions'] = ['user:read', 'post:edit']。前者耦合数据库结构，后者在用户权限变更后无法自动失效（session 不感知 DB 变更）。
- 每次请求校验时查一次 DB：
SELECT permissions FROM roles WHERE id = ?，确保权限实时性 - 加缓存可选，但必须设 TTL（比如 5 分钟），且用户权限更新后要主动清对应缓存 key
- 避免把权限字符串拼接进 SQL —— 用预处理语句防注入，例如检查权限时用
WHERE resource = ? AND action = ? AND role_id = ?
权限检查函数别写成全局 if-else 堆砌
写一个集中式的 can() 函数，接收 $resource、$action，内部查 role_permissions 关联表，返回布尔值。不要在每个控制器里手写 if ($_SESSION['role'] === 'admin') { ... }。
- 示例调用：
if (!can('post', 'delete')) { die('403'); } - 函数内优先查缓存（如 APCu 或 Redis），未命中再查 DB，查完立刻缓存结果（key 可为
"perm_{$role_id}_{$resource}_{$action}"） - 注意：
$resource和$action必须是白名单限定的字符串（如['user', 'post', 'comment']和['read', 'create', 'update', 'delete']），防止被传入恶意值绕过校验
路由层拦截比逻辑层判断更安全
权限校验代码放在所有业务逻辑之前，理想位置是前端控制器（如 index.php 或路由分发前），而不是等进到某个 PostController::delete() 里才检查。
- 例如 Apache + mod_rewrite 下，所有请求先过
index.php，在那里统一做can($route_resource, $route_action) - 如果用原生路由映射，把权限规则和路由绑定：
['POST', '/posts/{id}', 'post', 'delete']，启动时加载进内存，避免每次解析字符串 - 切忌在模板里用
<?php if (can('user', 'edit')): ?>...控制按钮显示——这只能隐藏 UI，后端接口仍可被直接调用
最易被忽略的是「权限继承」和「数据行级控制」：角色能删 post，不等于能删任意用户的 post。真实场景中，can('post', 'delete') 往往还得带上 $post->user_id 做二次校验，这部分没法靠通用函数兜底，得在业务逻辑里显式写。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
