3、角色与权限模型：角色的定义与层级设计、权限的粒度控制

好，咱们今天聊点硬核的。权限模型这东西，说白了就是「谁，能干什么，能看到什么」。我在风电行业摸爬滚打这些年，见过太多因为权限设计不合理导致的运维事故。有一次，一个刚入职的实习生误操作，把整个风场的 SCADA 参数给改了，结果全场风机停机两小时。嗯，从那以后，我对权限模型的设计就格外较真。

3.1 角色的定义与层级设计

角色是什么？它不是职位，而是一组权限的集合。我习惯把角色想象成一个「帽子」，你戴上什么帽子，就拥有什么能力。

在风场监控平台里，我通常把角色分为三层：

• 基础层：如「值班员」、「巡检员」。权限最小，只能看，不能动。
• 管理层：如「场长」、「运维主管」。可以操作设备、修改参数。
• 决策层：如「区域总监」、「集团管理员」。能看到所有风场的 KPI 和财务数据。

层级设计有个关键点：不要超过五层。为什么？你想想看，层级太多，权限继承关系会乱成一锅粥。我曾经在一个项目里看到七层角色嵌套，最后连管理员都搞不清某个角色到底能干啥。

3.2 权限的粒度控制

权限粒度，说白了就是「你能细到管多细」。我把它分成三个级别：

页面级权限

这是最粗的。比如「能不能看到风机实时监控页面」。我见过很多系统只做到这一步，结果就是：要么全能看到，要么全看不到。太粗暴了。

按钮级权限

这个就细一些了。比如「启动风机」按钮，只有场长能点；「查看历史曲线」按钮，值班员也能点。我在做某个海上风场项目时，就专门给「紧急停机」按钮加了个权限校验——只有两个人能按，其他人点了也没反应。

// 按钮级权限示例（伪代码）
if (user.hasPermission('emergency_stop')) {
    document.getElementById('stopBtn').disabled = false;
} else {
    document.getElementById('stopBtn').disabled = true;
    showToast('您没有紧急停机权限');
}

数据级权限

这是最细的，也是最容易出问题的。比如：

• 华北区的运维主管，只能看到华北区的风机数据
• 同一个风场里，A 机组的数据只有 A 机组的负责人能看到
• 财务数据只有财务角色能看到，运维人员看不到

3.3 角色继承与互斥

角色继承，说白了就是「子角色自动拥有父角色的权限」。比如「高级运维员」继承「初级运维员」的所有权限，再加一些高级操作权限。

但这里有个坑：继承不要超过三层。我曾经见过一个系统，角色继承链长达五层，结果改一个父角色的权限，下面所有子角色都受影响，最后谁都不敢改。

角色互斥，就是「一个人不能同时拥有两个互斥的角色」。比如：

• 「审批人」和「申请人」不能是同一个人
• 「审计员」和「操作员」不能是同一个人
• 「安全管理员」和「系统管理员」不能是同一个人

这个在风场里特别重要。你想想看，如果一个人既能申请备件，又能审批备件，那岂不是想换啥就换啥？

3.4 最小权限原则

这个原则，说白了就是「给一个人刚刚好的权限，不多给一丁点」。我习惯用一句话来检验：如果一个人离职了，他的权限被回收后，系统还能正常运行吗？

具体怎么做？我总结了三条：

1. 默认拒绝：所有权限默认关闭，只有明确授予才开放
2. 按需授予：只给完成工作所必需的权限
3. 定期审计：每季度检查一次权限列表，收回不再需要的权限

好了，这一章的内容就这些。权限模型设计得好，系统就稳；设计得不好，早晚出问题。下一章咱们聊聊具体的权限管理流程和工具实现。

---