4. 资源与操作定义：风场监控中的资源类型与操作类型
好，咱们进入正题。权限管理这件事，说白了就是回答三个问题：谁能对什么做什么。上一章我们聊了「谁」——用户和角色。这一章，我们来拆解「什么」和「做什么」。
在风场监控平台里，「什么」就是资源，比如风机、升压站、测风塔。「做什么」就是操作，比如查看、控制、配置、删除。这两者组合起来，就构成了权限控制的基本单元。
我个人习惯把这一步叫做「资源与操作的原子化定义」。为什么强调「原子化」？因为我在项目中遇到过，有人把「查看风机转速」和「控制风机启停」混在一个权限里，结果运维人员不小心点了停机按钮……嗯，那场面挺尴尬的。
4.1 资源类型：风场里的三类核心资产
风场监控平台里，资源不是凭空想象的。它对应着物理世界里的真实设备。我一般把它们分成三类：
- 风机（Wind Turbine）：发电的核心单元。每台风机有独立的控制器、传感器、变桨系统等。
- 升压站（Substation）：电能的汇集与升压节点。包括主变、开关柜、SVG等设备。
- 测风塔（Meteorological Mast）：气象数据的采集点。风速、风向、温度、气压等数据从这里来。
你想想看，这三类资源的权限需求是完全不同的。风机需要精细到单台控制，升压站更关注整体状态监控，测风塔则主要是数据读取。如果把它们混在一起管理，权限粒度就太粗了。
核心原则：每种资源类型都应该有独立的权限定义。不要试图用「设备」一个概念覆盖所有。
4.2 操作类型：你能对资源做什么
操作类型，就是用户对资源能执行的动作。我一般定义四个基本操作：
| 操作类型 | 说明 | 典型场景 |
|---|---|---|
| 查看（View） | 读取资源的状态、数据、历史记录 | 查看风机实时功率、查看升压站电压 |
| 控制（Control） | 对资源下发指令，改变其运行状态 | 启动/停止风机、调节无功出力 |
| 配置（Configure） | 修改资源的参数、阈值、策略 | 修改风机功率曲线、调整保护定值 |
| 删除（Delete） | 从系统中移除资源或相关数据 | 删除退役风机、清理历史报警 |
这里有个坑，我踩过。曾经有个项目，把「配置」和「控制」合并成一个「管理」权限。结果现场工程师想调整一下风机参数，结果发现连停机按钮都一起暴露了。后来我们花了整整一周重新梳理权限矩阵……所以，操作类型一定要拆开定义。
避坑指南：我曾经见过一个平台，把「删除」操作和「查看」操作放在同一个角色里。结果一个实习生不小心把整个风场的历史数据全删了。嗯，从那以后，我坚持「删除」必须单独授权，且需要二次确认。
4.3 资源树：把风场组织成一棵树
风场里的资源不是孤立的。它们有层级关系。比如：一个风场下有多个回路，每个回路下有多台风机。升压站可能服务于整个风场，测风塔则分布在风场不同位置。
我习惯用资源树来组织这些关系。树根是风场，树枝是区域或回路，树叶是具体的设备。这样做的好处是：权限可以沿着树结构继承。
举个例子：
风场A
├── 升压站A1
├── 回路1
│ ├── 风机WT001
│ ├── 风机WT002
│ └── 风机WT003
├── 回路2
│ ├── 风机WT004
│ └── 风机WT005
└── 测风塔M01如果给某个用户授予「回路1」的查看权限，那么WT001、WT002、WT003的查看权限会自动继承。不需要逐台配置。这在风场规模达到上百台风机时，能省下大量时间。
我的经验：资源树的深度建议控制在3-4层。太深了，权限继承的逻辑会变得复杂，容易出错。我见过一个项目搞了7层树结构，最后连管理员自己都搞不清权限是怎么继承的。
4.4 资源组：灵活应对非树形需求
资源树能解决大部分问题，但总有例外。比如：
- 你想把「所有需要检修的风机」临时归为一组，方便批量操作。
- 你想把「升压站A」和「测风塔M01」放在一起，给某个外部专家查看。
- 你想按「电压等级」或「投运年份」来分组，而不是按物理位置。
这时候，资源组就派上用场了。资源组是一个虚拟集合，可以跨树结构任意组合资源。
我一般这样设计：
- 每个资源可以属于多个资源组。
- 资源组可以嵌套（组里套组）。
- 权限可以授予到资源组级别。
举个例子：
资源组：2024年检修风机
├── 风机WT002（来自回路1）
├── 风机WT004（来自回路2）
└── 风机WT007（来自回路3）给某个运维团队授予这个资源组的「控制」权限，他们就能在检修期间对这三台风机进行启停操作，而不会影响到其他风机。
核心区别：资源树是静态的、物理的；资源组是动态的、逻辑的。两者互补，缺一不可。
4.5 资源与操作的组合：权限矩阵
把资源类型和操作类型组合起来，就得到了权限矩阵。我一般用一张表来定义：
| 资源类型 | 查看 | 控制 | 配置 | 删除 |
|---|---|---|---|---|
| 风机 | ✅ | ✅ | ✅ | ❌ |
| 升压站 | ✅ | ✅ | ✅ | ❌ |
| 测风塔 | ✅ | ❌ | ✅ | ❌ |
你看，测风塔通常不需要「控制」操作——你不能让测风塔「启动」或「停止」，它就是个被动采集数据的设备。而「删除」操作，我一般对所有核心资源都禁用，只开放给系统管理员。
这个矩阵，就是权限系统的核心骨架。后续的角色定义、策略配置，都是在这个矩阵上做文章。
4.6 知识体系：一张图看懂
说了这么多，咱们用一张图来总结一下。这张图展示了资源、操作、资源树、资源组之间的关系。
这张图的核心逻辑是：资源类型 + 操作类型 → 权限矩阵 → 应用到资源树和资源组。你想想看，有了这个框架，不管风场规模多大、设备类型多复杂，权限管理都能做到清晰可控。
一个小建议：在实际项目中，我建议先定义好资源类型和操作类型，再设计资源树和资源组。顺序不要搞反了。否则你会发现，权限定义越做越乱，最后不得不返工。
好，这一章就到这里。资源与操作的定义，是权限管理的基石。下一章我们会聊如何把这些原子权限组合成角色，以及角色之间如何继承和覆盖。嗯，到时候见。