本文由 FlintHub 开发文档归档发布。原始文档日期见标题前缀，来源：7月5日复制的资料/用户组权限计划.md。

用户组与权限系统 — 实现计划

目标：增加用户组功能，实现按版块控制浏览、发帖、回复权限

一、现状分析

二、设计方案

核心思路

用户 → 用户组（手动分配）→ 粗粒度权限：能浏览哪些版块、能否发帖/回复
     → 等级（自动升级）  → 细粒度限制：每日发帖上限、附件大小、免验证码

用户组管"能不能做某件事"，等级管"能做多少"。两种权限叠加生效——用户先有用户组的发帖权限，才能谈等级带来的"每天能发几帖"。

数据模型

新增表 1：user_groups（用户组）

新增表 2：category_permissions（版块权限）

修改表：users

默认数据

三、涉及文件清单

3.1 数据库

3.2 新增文件

3.3 修改文件

四、实现步骤

第 1 步：建表 + 默认数据（0.5 天）

CREATE TABLE user_groups (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    color VARCHAR(20) DEFAULT '#666',
    is_default TINYINT(1) DEFAULT 0,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO user_groups (id, name, color, is_default) VALUES
(1, '普通会员', '#666', 1),
(2, 'VIP会员', '#f39c12', 0),
(3, '版主', '#27ae60', 0),
(4, '管理员', '#e74c3c', 0);

CREATE TABLE category_permissions (
    id INT AUTO_INCREMENT PRIMARY KEY,
    category_id INT NOT NULL,
    group_id INT NOT NULL,
    can_view TINYINT(1) DEFAULT 1,
    can_post TINYINT(1) DEFAULT 1,
    can_reply TINYINT(1) DEFAULT 1,
    UNIQUE KEY uk_cat_group (category_id, group_id),
    FOREIGN KEY (category_id) REFERENCES categories(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

ALTER TABLE users ADD COLUMN group_id INT DEFAULT 1;

第 2 步：Permission Helper（0.5 天）

class Permission
{
    // 检查用户是否有权浏览版块
    public static function canView($categoryId, $userId = null): bool
    // 检查是否有权发帖
    public static function canPost($categoryId, $userId = null): bool
    // 检查是否有权回复
    public static function canReply($threadId, $userId = null): bool
    // 获取用户组信息
    public static function getUserGroup($userId): array
}

第 3 步：后台管理界面（1 天）

• 用户组管理：CRUD 用户组、设置默认组
• 版块权限设置：以版块为维度，勾选每个组的浏览/发帖/回复权限
• 用户管理：编辑用户时可选择所属用户组

第 4 步：前端权限拦截（0.5 天）

• ForumController::category() → 检查 canView()
• ThreadController::show() → 检查 canView()
• PostController::create() → 检查 canPost()
• ThreadController::show() 的回复表单 → 检查 canReply()

第 5 步：现有等级系统的融合（已有，无需改动）

points 和 level 字段保持原样运行，与用户组互不干扰：

用户组 → 控制权限（能不能做某件事）
等级   → 展示 badge（做了事积累的荣誉）

五、后续可扩展

六、工作量估计

七、我的想法

1. 等级和权限分开是对的——等级是"荣誉"，用户组是"权限"，两者互不依赖。现在的 points/level 系统可以原封不动保留。

1. 权限检查点要精准——只需拦截三个关键入口：浏览版块列表、点击发帖按钮、提交回复表单。不需要在 Model 层做权限检查，Controller 层拦截就够了。

1. 默认权限宽松——新增版块时默认所有组都有全部权限，管理员只需针对需要限制的版块去关闭某些组的权限，减少配置负担。

1. 管理员不受限制——group_id=4（管理员组）跳过所有权限检查，确保管理员不会把自己锁在外面。

要不要开始做？从第 1 步建表开始。