本文目录导读：
在PHP项目中实现用户分层（用户权限管理、会员等级体系或角色管理）通常有以下几个核心方法，具体选择哪种，取决于你的业务复杂度。
下面从简单到复杂，介绍几种常见的实现方案，并给出代码示例。
最简单的：基于数据库字段的等级/角色判断
适用于非常简单的场景,比如区分普通用户、VIP用户、管理员。
实现方式：
在 users 表中增加一个字段，如 role (角色) 或 level (等级)。
数据库表结构示例：
CREATE TABLE users (
id INT PRIMARY KEY,
username VARCHAR(50),
password_hash VARCHAR(255),
role ENUM('user', 'vip', 'admin') DEFAULT 'user',
level TINYINT DEFAULT 1, -- 1:普通, 2:银卡, 3:金卡
created_at DATETIME
);
PHP 代码示例：
<?php
// 假设已经从数据库获取了用户信息
$user = [
'id' => 1,
'role' => 'vip',
'level' => 2
];
// 权限检查函数
function checkAccess($user, $requiredRole) {
$roleHierarchy = ['user' => 1, 'vip' => 2, 'admin' => 3];
$userRank = $roleHierarchy[$user['role']] ?? 0;
$requiredRank = $roleHierarchy[$requiredRole] ?? 0;
return $userRank >= $requiredRank;
}
// 使用
if (checkAccess($user, 'vip')) {
echo "访问VIP内容";
}
// 基于等级：检查是否达到银卡等级
if ($user['level'] >= 2) {
echo "享受银卡折扣";
}
优点： 简单直接，适合小项目。
缺点： 扩展性差，权限逻辑和业务代码耦合严重。
基于角色的访问控制（RBAC）—— 推荐
适用于需要精细权限控制的中大型项目,用户不直接与权限关联，而是通过“角色”来关联。
核心表结构（三张核心表 + 两张关联表）：
users：用户表roles：角色表（如：超级管理员、编辑、VIP用户）permissions：权限表（如：create_post, delete_user, view_admin）role_user：用户与角色的多对多关联permission_role：角色与权限的多对多关联
SQL 建表示例（简化版）：
-- 1. 用户表 (略)
-- 2. 角色表
CREATE TABLE roles (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) UNIQUE NOT NULL,
slug VARCHAR(50) UNIQUE NOT NULL -- 用于代码判断，如 'admin', 'editor'
);
-- 3. 权限表
CREATE TABLE permissions (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100) UNIQUE NOT NULL,
slug VARCHAR(100) UNIQUE NOT NULL -- 如 'create_post', 'delete_any_user'
);
-- 4. 用户-角色关联表
CREATE TABLE role_user (
user_id INT NOT NULL,
role_id INT NOT NULL,
PRIMARY KEY (user_id, role_id),
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
FOREIGN KEY (role_id) REFERENCES roles(id) ON DELETE CASCADE
);
-- 5. 角色-权限关联表
CREATE TABLE permission_role (
role_id INT NOT NULL,
permission_id INT NOT NULL,
PRIMARY KEY (role_id, permission_id),
FOREIGN KEY (role_id) REFERENCES roles(id) ON DELETE CASCADE,
FOREIGN KEY (permission_id) REFERENCES permissions(id) ON DELETE CASCADE
);
PHP 实现逻辑（核心示例）：
<?php
class UserAuthorization
{
private $db;
private $permissionsCache = [];
// 1. 获取用户的所有角色ID
public function getUserRoleIds(int $userId): array {
$stmt = $this->db->prepare("SELECT role_id FROM role_user WHERE user_id = ?");
$stmt->execute([$userId]);
return array_column($stmt->fetchAll(), 'role_id');
}
// 2. 通过角色ID获取所有权限slug
public function getPermissionsByRoleIds(array $roleIds): array {
if (empty($roleIds)) return [];
$placeholders = implode(',', array_fill(0, count($roleIds), '?'));
$sql = "SELECT DISTINCT p.slug FROM permissions p
JOIN permission_role pr ON p.id = pr.permission_id
WHERE pr.role_id IN ($placeholders)";
$stmt = $this->db->prepare($sql);
$stmt->execute($roleIds);
return array_column($stmt->fetchAll(), 'slug');
}
// 3. 检查用户是否有某个特定权限
public function hasPermission(int $userId, string $permissionSlug): bool {
// 使用缓存，避免重复查询
if (!isset($this->permissionsCache[$userId])) {
$roleIds = $this->getUserRoleIds($userId);
$this->permissionsCache[$userId] = $this->getPermissionsByRoleIds($roleIds);
}
return in_array($permissionSlug, $this->permissionsCache[$userId]);
}
// 4. 在控制器或中间件中使用
public function checkPermission($userId, $permissionSlug) {
if (!$this->hasPermission($userId, $permissionSlug)) {
throw new \Exception('无权限访问', 403);
}
}
}
使用示例（在控制器或中间件中）：
// 在控制器方法开头调用
if (!$auth->hasPermission($currentUserId, 'delete_any_user')) {
// 返回403或跳转
return response('无权删除用户', 403);
}
// 继续执行删除逻辑...
优点： 灵活、可扩展、权限与业务分离。
缺点： 需要维护多张表，查询量稍大（但也因此常结合缓存如Redis来优化）。
基于门的策略（Laravel 风格，适合框架用户）
如果你使用像 Laravel 这样的现代PHP框架，可以利用框架自带的 Gate 和 Policy 系统。
实现步骤（以 Laravel 为例）：
- 定义
User模型中的角色/等级关系（可以基于上面 RBAC 的表或简单字段）。 - 在
App\Providers\AuthServiceProvider中定义 Gate 或 Policy。 - 在控制器中使用
$this->authorize()或Gate::allows()。
// 1. 定义 Policy (PostPolicy)
public function update(User $user, Post $post) {
return $user->id === $post->user_id || $user->role === 'admin';
}
// 2. 在控制器中使用
public function update(Request $request, Post $post) {
$this->authorize('update', $post); // 自动返回403或抛出异常
// 更新逻辑...
}
优点： 原生集成、代码简洁、社区成熟。
缺点： 依赖特定框架，不适用于原生PHP。
基于分层模型的会员等级（积分/经验值体系）
适用于像电商平台、游戏、社区（如：Lv1 - Lv10 会员）这类需要根据用户行为自动升级的场景。
核心思路：
users表增加字段：points（积分）、experience（经验值）、level_id（等级ID）。levels表：定义每个等级所需的条件（如min_points,max_points,discount_rate等）。
PHP 示例（升级逻辑）：
<?php
// 当用户获得积分时
function addPoints(int $userId, int $points) {
// 1. 更新用户积分
$db->query("UPDATE users SET points = points + $points WHERE id = $userId");
// 2. 查询用户最新积分
$user = $db->query("SELECT points, level_id FROM users WHERE id = $userId")->fetch();
// 3. 根据积分找到对应的新等级
$newLevel = $db->query(
"SELECT id FROM levels WHERE min_points <= ? AND (max_points IS NULL OR max_points >= ?)
ORDER BY min_points DESC LIMIT 1",
[$user['points'], $user['points']]
)->fetch();
// 4. 如果等级变了，更新
if ($newLevel && $newLevel['id'] != $user['level_id']) {
$db->query("UPDATE users SET level_id = ? WHERE id = ?", [$newLevel['id'], $userId]);
// 可以在这里触发通知、赠送礼包等
}
}
优点： 自动化、激励用户。
缺点： 需要额外维护等级规则表。
如何选择？
| 项目规模 / 需求 | 推荐方案 |
|---|---|
| 小型项目、个人博客 | 数据库字段（role / level） |
| 中型项目、需要精细权限 | RBAC（角色-权限） |
| 大型电商、社区、游戏 | RBAC + 等级体系（Levels） |
| 使用Laravel/Symfony | 框架自带的Gate/Policy（底层通常是RBAC） |
最后建议：
- 不要过度设计,初期如果只有两种用户（普通、付费），用简单的字段判断即可。
- 一旦出现“不同角色对不同资源（如文章、订单）有不同的增删改查权限”，就需要立即升级到RBAC。
- 如果用户分层还涉及到积分、升级奖励、折扣规则，则需要同时实现等级表 + 权限系统，二者可以共存但管的是不同维度。
