权限等级设计：访客、注册用户、VIP、管理员

权限等级设计看起来只是几个角色名，落地时却容易含糊：访客能看什么，注册用户默认能做什么，VIP 由谁授予，管理员管到哪一层。MDP 既有公开内容，也有登录可见、VIP 可见、管理员可见和指定用户资源，这些边界不写清楚，资源下载和后台管理就会混乱。本文围绕 PHP 后台开发，把等级拆成可检查的角色与权限点，并给出对应的数据表结构和判断逻辑。

先分清角色与权限点

角色是身份的集合，权限点是具体操作或资源的开关。访客、注册用户、VIP、管理员是四种角色，但“查看文章”“下载附件”“编辑用户”“查看日志”才是权限点。角色与权限点分开存，比在页面里写 if ($user->vip) { ... } 更利于扩展。假设以后出现“VIP 可下载但不可评论”的需求，只需调整权限点，不必改动角色判断。

数据表可以这样设计：用户表存 role 字段，取值如 guest、user、vip、admin；角色表存角色名称与说明；权限点表存权限标识与描述；角色与权限点通过中间表关联。管理员也是一种角色，不单独建一套逻辑，后台入口再校验一次管理员身份即可。

判断逻辑放在哪里

PHP 中不建议在每个页面顶部重复写判断。统一入口（如 index.php 或路由分发文件）里做一次权限校验，把当前用户角色和所需权限点传入一个函数，返回布尔值。这样页面只关心“有没有权限”，不关心“为什么有”。

一个短小的原生 PHP 示例：

```php
function hasPermission($userRole, $requiredPermission, $rolePermissions) {
if ($userRole === 'admin') {
return true; // 管理员默认拥有全部权限
}
if (!isset($rolePermissions[$userRole])) {
return false;
}
return in_array($requiredPermission, $rolePermissions[$userRole], true);
}

// 使用示例：假设 $rolePermissions 从数据库加载
$rolePermissions = [
'guest' => ['view_public'],
'user' => ['view_public', 'view_member'],
'vip' => ['view_public', 'view_member', 'download_vip'],
];

if (hasPermission($currentUserRole, 'download_vip', $rolePermissions)) {
// 允许下载
} else {
// 提示无权限
}
```

注意，管理员直接返回 true 是简化处理。若后台有更细的权限划分（如某些管理员只能管理内容不能管理用户），则管理员也应走权限点匹配，而不是一刀切。

前台展示与后台维护要对应

权限设计常见的问题是前台页面做了限制，后台却没有对应的维护入口。例如前台只显示 VIP 资源，后台却没有设置某个资源为 VIP 可见的开关，运营人员只能改数据库，这不叫完成。

后台资源编辑页应包含“可见角色”或“所需权限点”的选择项，保存后写入资源表或资源与权限关联表。前台读取资源列表时，先查出当前用户角色拥有的权限点集合，再过滤资源。过滤逻辑放在模型层或数据访问层，不要在模板里用 if 判断每条记录。

检查方法：用一个普通注册用户登录，确认看不到 VIP 资源；再用 VIP 账号登录，确认能看到。同时检查后台能否修改资源的可见范围，修改后前台立即生效。

容易出错的地方

访客与注册用户的边界。 有些系统把“登录后可见”理解为“注册用户可见”，但访客通过分享链接直接访问详情页时，URL 可能绕过列表页的权限控制。因此详情页本身也要校验，不能只靠列表页隐藏入口。

VIP 状态与到期时间。 VIP 若有过期时间，不能只存一个 is_vip 布尔值。应存 vip_expires_at 字段，判断时用当前时间与到期时间比较。到期后自动降级为注册用户，这个逻辑可以在每次请求时检查，也可以由定时任务统一处理，但前者更简单可靠。

管理员权限过大。 管理员能看所有内容，但操作日志不能少。谁在什么时间把某个用户设为 VIP、修改了哪篇资源的可见范围，这些记录要写入日志表。没有日志，出了问题无法追溯。

错误提示不明确。 无权限时返回 403 页面或 JSON 错误信息，不要只显示空白页。前台用户需要知道“登录后可查看”还是“VIP 专享”，后台管理员需要知道“当前角色无权执行此操作”。区分提示语能减少误判。

检查清单

按以下顺序逐项验证，能覆盖大部分权限问题：

1. 用访客身份访问所有 URL，确认公开内容可见、受保护内容不可见且提示明确。
2. 用注册用户身份访问，确认默认权限生效，不能看到 VIP 或管理员内容。
3. 用 VIP 身份访问，确认 VIP 资源可见，到期后自动降级。
4. 用管理员身份登录后台，确认能维护用户角色、资源可见范围和权限点关联。
5. 检查操作日志，确认关键操作有记录。
6. 换浏览器或设备重新走一遍流程，避免缓存或会话问题掩盖真实状态。

后续扩展方向

权限变更日志和到期提醒是自然的下一步。权限变更日志记录每次角色调整的操作者、对象、时间和原因；到期提醒可以在用户登录时检查 VIP 剩余天数，剩余不足时在页面显示提示。这些功能不需要改动核心权限结构，只需在现有表上增加字段和日志记录。

权限设计的核心不是写多少代码，而是边界清楚、判断集中、后台可维护。把角色与权限点分开，把判断逻辑放在统一入口，把可见范围做成后台可配置项，这套结构能支撑后续多数功能扩展。