第四章：用户与角色管理——权限体系的基石
好，我们进入第四章。这一章讲的是用户与角色管理，说白了就是解决「谁」能「做什么」的问题。我在MES项目里见过太多权限混乱的案例，有的工厂甚至一个操作员能改工艺参数，想想都后怕。
4.1 用户生命周期管理
用户不是一成不变的。从入职到离职，每个阶段都要管好。
核心观点：用户生命周期管理，就是管好「账号的出生、活着、死亡」。
4.1.1 用户创建与激活
新员工入职，HR系统推过来一条消息。MES系统收到后，自动创建账号。我建议走「预激活」模式——账号先创建，但状态是「未激活」。等员工完成安全培训，管理员点一下激活按钮。
为什么这么做？我曾经遇到过一个案例：HR批量导入账号，结果有个账号被离职员工冒用了。从那以后，我坚持所有新账号必须手动激活。
| 阶段 | 状态 | 可操作 |
|---|---|---|
| 创建 | 未激活 | 无任何权限 |
| 激活 | 正常 | 按角色授权 |
| 锁定 | 锁定 | 仅查看 |
| 归档 | 已删除 | 不可用 |
4.1.2 用户禁用与归档
员工离职，账号不能直接删。我习惯的做法是：先禁用，保留30天。这30天里，审计可以查操作记录。30天后自动归档，数据保留但账号不可用。
小技巧：归档时把用户从所有角色中移除，但保留操作日志的关联。这样既安全，又满足合规要求。
4.2 角色继承与互斥
角色设计是权限体系的核心。设计得好，管理轻松；设计得烂，天天救火。
4.2.1 角色继承
角色继承，说白了就是「子角色拥有父角色的所有权限」。比如「高级操作员」继承「操作员」的所有权限，再加一些高级功能。
我见过一个工厂，每个角色都从零开始配权限，结果配了200多个角色，管理员崩溃了。用继承，你只需要维护基础角色，派生角色自动继承。
// 角色继承示例（伪代码）
class Role {
string name;
List<Permission> permissions;
Role parentRole; // 父角色
}
// 高级操作员继承操作员
Role operator = new Role("操作员");
operator.addPermission("view_production_order");
Role seniorOperator = new Role("高级操作员");
seniorOperator.setParentRole(operator);
seniorOperator.addPermission("modify_production_order");
// 高级操作员自动拥有 view_production_order 权限注意：继承层级不要太深。我建议最多3层，否则权限追溯会变得非常困难。我曾经接手过一个5层继承的系统，查一个用户的权限要翻半天。
4.2.2 角色互斥
角色互斥，就是某些角色不能同时分配给同一个人。比如「质检员」和「生产操作员」不能是同一个人——自己生产自己检验，那还得了？
为什么会这样？这是典型的「职责分离」原则。在MES里，常见的互斥对包括：
- 生产操作员 vs 质检员
- 物料领料员 vs 物料盘点员
- 工艺参数设置员 vs 工艺参数审核员
- 系统管理员 vs 审计员
实现上，我习惯在角色定义时声明互斥组。分配角色时系统自动校验。
// 角色互斥示例
class Role {
string name;
string mutexGroup; // 互斥组，同一组内角色互斥
}
Role inspector = new Role("质检员");
inspector.mutexGroup = "quality";
Role operator = new Role("操作员");
operator.mutexGroup = "production";
// 分配角色时检查
function assignRole(user, role) {
if (user.hasRoleInMutexGroup(role.mutexGroup)) {
throw new Exception("该用户已有互斥角色，无法分配");
}
user.addRole(role);
}4.3 最小权限原则实战
最小权限原则，听起来高大上，其实就一句话：给用户刚刚好的权限，不多给一分。
我在项目中遇到过一件事：一个车间主任的账号被用来删了生产记录。查下来发现，这个账号居然有「删除生产记录」的权限。而车间主任只需要查看和审批，根本不需要删除。这就是典型的最小权限没做好。
4.3.1 如何落地最小权限
我总结了一个三步法：
- 梳理岗位职责：每个岗位到底需要做什么？列出具体操作。
- 映射到权限：每个操作对应哪些系统权限？比如「查看工单」对应 view_work_order，「修改工单」对应 modify_work_order。
- 创建角色：把权限打包成角色，一个角色对应一个岗位。
你想想看，如果每个岗位都这样梳理，权限就不会乱。但现实中，很多工厂直接给管理员权限，图省事。嗯，这里要注意，省事一时爽，出事火葬场。
实战建议：每个新角色创建后，先给一个测试账号试用一周。让用户自己反馈「这个权限我根本用不到」「那个权限我缺了」。一周后调整，再正式上线。
4.3.2 权限审计与回收
权限不是给了就完事了。我建议每季度做一次权限审计。查什么？
- 有没有离职员工的账号还在活跃？
- 有没有用户的权限远超岗位需求？
- 有没有角色被分配给了不该有的人？
审计结果出来后，该回收的回收，该调整的调整。我曾经帮一个客户做审计，发现一个实习生居然有「修改工艺参数」的权限。一问才知道，是管理员手滑点错了。还好发现得早，不然工艺参数被改了，整条产线都得停。
4.4 本章知识体系
下面这张图，是我梳理的本章核心逻辑。你看一眼，就能明白用户、角色、权限之间的关系。
这张图把用户、角色、权限的关系讲清楚了。用户通过角色获得权限，角色之间可以继承也可以互斥。最小权限原则贯穿始终。
我的习惯：每次设计新角色，我都会问自己三个问题：这个角色真的需要这个权限吗？有没有更小的权限可以替代？如果给错了，后果是什么？问完这三个问题，基本不会出错。
好，这一章就到这里。用户与角色管理是权限体系的基石，打好基础，后面的安全架构才能稳。下一章我们聊认证与授权，到时候见。
公众号:蓝海资料掘金营，微信deep3321