📚 课程目录第3章用户管理模块

3、用户管理模块：用户创建、用户禁用/启用、用户信息维护、用户组管理

用户管理，说白了就是配方系统的「门禁系统」。谁可以进来、进来能干什么、干完了怎么走，全得靠它管着。我见过不少项目，配方逻辑写得再漂亮，用户管理一塌糊涂，最后上线第一天就被人钻了空子。

这一章，咱们就把用户管理模块的四个核心功能拆开揉碎。你想想看，一个配方系统里，操作员、工艺员、质检员、管理员，角色五花八门。怎么让这些人各司其职，不出乱子？

3.1 用户创建：从零到一的关键步骤

用户创建不是简单的「填个用户名、设个密码」就完事了。我在项目中遇到过，有人直接用「admin」「123456」这种弱口令，结果被扫出来，整个配方库差点被删。嗯，从那以后，我对用户创建这块就格外敏感。

一个靠谱的用户创建流程，至少得包含这几步：

身份校验：只有管理员或超级管理员才有创建权限。普通操作员不能自己注册。
信息采集：用户名、真实姓名、工号、所属部门、联系方式。别漏了「所属部门」，后面做用户组管理时有大用。
密码策略：长度至少8位，必须包含大小写字母、数字、特殊字符。我习惯在创建时生成一个临时密码，强制用户首次登录修改。
角色绑定：创建时直接分配角色，比如「配方编辑员」「审核员」「管理员」。角色决定了用户能看到哪些配方、能改哪些参数。

核心原则：用户创建时，权限分配越细，后期维护越省心。别想着「先给个管理员，后面再调」，这种偷懒做法迟早要还债。

来看一段伪代码，展示用户创建的核心逻辑：

function createUser(userData) {
    // 1. 校验当前操作者权限
    if (!currentUser.hasPermission('USER_CREATE')) {
        throw new Error('无创建用户权限');
    }
    
    // 2. 校验输入数据完整性
    if (!userData.username || !userData.password) {
        throw new Error('用户名和密码不能为空');
    }
    
    // 3. 密码强度校验
    if (!isPasswordStrong(userData.password)) {
        throw new Error('密码不符合安全策略');
    }
    
    // 4. 检查用户名唯一性
    if (userRepository.existsByUsername(userData.username)) {
        throw new Error('用户名已存在');
    }
    
    // 5. 创建用户并分配默认角色
    const newUser = userRepository.create({
        username: userData.username,
        passwordHash: hashPassword(userData.password),
        realName: userData.realName,
        department: userData.department,
        status: 'ACTIVE',
        roleIds: userData.roleIds
    });
    
    return newUser;
}

3.2 用户禁用/启用：灵活控制，不留死角

用户离职了怎么办？账号被盗了怎么办？临时工到期了怎么办？

别急着删用户。我建议的做法是「禁用」而不是「删除」。为什么？因为配方系统里，用户和配方、操作日志、审核记录都是关联的。你把人删了，历史数据就变成了一堆孤儿记录，查都查不到是谁操作的。

操作	适用场景	影响范围	恢复难度
禁用	员工离职、账号异常、临时停职	仅影响登录，历史数据保留	低，启用即可恢复
删除	测试账号清理、数据迁移	用户及关联数据全部清除	高，需从备份恢复

注意：禁用用户时，一定要检查该用户是否有「未完成」的配方审核任务。我曾经遇到过，把正在审核配方的用户禁用了，结果那个配方卡在「审核中」状态整整两周，生产线差点停摆。

启用操作相对简单，但也要做一次「合规检查」：该用户是否还在原部门？角色是否仍然有效？如果部门都撤销了，启用也没意义。

3.3 用户信息维护：别让数据变成垃圾

用户信息维护，听起来很基础，但做不好就是灾难。你想想看，一个配方系统跑了三年，里面全是「张三」「李四」这种名字，工号对不上，部门早换了好几轮。到时候审计来了，你拿什么交代？

我习惯把用户信息维护分成两类：

基本信息：姓名、工号、联系方式、部门。这些信息允许用户自己修改一部分（比如联系方式），但工号和部门必须由管理员维护。
安全信息：密码、密保问题、MFA 绑定。这些信息必须严格管控，修改时需要二次验证。

这里有个小技巧：每次用户信息变更，都生成一条变更日志。谁改的、改了啥、什么时候改的，全记下来。审计的时候，这就是你的护身符。

我的习惯：在用户信息维护页面，加一个「最后登录时间」和「最后修改时间」的展示。这样管理员一眼就能看出哪些用户是「僵尸账号」，该清理就清理。

3.4 用户组管理：批量授权的利器

单个用户授权太慢了。一个车间几十号人，难道要一个一个配权限？

用户组就是来解决这个问题的。你把「车间操作员」设为一个组，把「配方审核员」设为另一个组。新来一个人，直接往组里一扔，权限自动继承。省心省力。

用户组管理的核心设计：

组-角色绑定：一个用户组可以绑定多个角色。比如「高级操作员」组，既有「配方查看」权限，又有「配方参数微调」权限。
组-用户关联：一个用户可以属于多个组。权限取并集。但要注意，如果两个组对同一个资源有冲突权限（比如一个允许删除，一个禁止删除），需要定义「优先级」或「拒绝优先」规则。
组层级：用户组可以嵌套。比如「生产部」下面有「车间A组」「车间B组」。子组自动继承父组的权限。

下面这张图，展示了用户、用户组、角色、权限之间的关系：

避坑指南：用户组别搞太多层级。我曾经见过一个系统，用户组嵌套了7层，权限继承关系比蜘蛛网还复杂。最后谁也说不清某个用户到底有什么权限。我的建议是，最多3层：公司级 → 部门级 → 岗位级。再多就失控了。

3.5 用户管理的常见陷阱

最后，分享几个我踩过的坑，希望能帮你省点时间：

陷阱一：用户和角色强耦合。别把角色直接写在用户表里。用户和角色之间加一层「用户组」，灵活性会高很多。
陷阱二：禁用用户不清理会话。禁用用户后，如果他已经登录了，会话还在有效期。一定要强制踢下线，或者让 token 失效。
陷阱三：用户信息维护没有版本控制。谁改了用户的部门？什么时候改的？没有记录，审计来了就是一脸懵。
陷阱四：用户组权限变更不通知。你把「车间操作员组」的权限改了，组里的20个人可能完全不知道。最好加个通知机制，或者让用户下次登录时重新确认权限。

嗯，用户管理这块，说白了就是「把对的人，放到对的位置，给对的权限」。做扎实了，后面的配方权限配置才能站得住脚。