波仔
📹 第十一章 GB／T 28181国标平台案例应用
📄 一句话概括

分域管理是「按组织架构建一棵树」，树的好处是权限天然继承。 可授权范围的数量等于节点数——所以「树要多细」直接决定「权限能控多细」。

📝 本节和前面几节的关系

上一节讲「怎么接设备」，这一节讲「接进来之后怎么分给人看」。 分域这件事一旦定下来，后面每一次加功能都要顺着它走，所以它比接口设计更需要提前想清楚。

一、一棵树，三层

典型结构是「市局—区局—派出所」三层：一市、五区、每区八个派出所，一共四十六个节点。 节点数不多，但它是「权限的坐标系」： 每个节点都能单独授权，所以「能授权的范围」就有四十六种。 权限继承是白送的：给市局授权，等于给整棵树授权，因为「市局的范围」按定义就包含下级。 这一点在实现上很省事：不用真的给每个下级写一条记录，只要「查的时候带上子树」就行。

二、树该有多深

树浅好维护，但粒度粗；树深粒度细，但节点多、维护成本高。 成熟平台的常见选择是「树做到区一级，再往下的例外用设备组补」—— 这样树不会失控，例外也有地方放。 为什么不让树一直长下去： 因为每加一层，界面上就多一层要展开，而「展开五层才找到一台设备」是没人愿意用的。 所以「设备组」不是冗余设计，是「给树减负」的设计。树管「归属」，组管「临时要看的那一批」。

三、审计：谁授的权

权限系统最怕的不是「授错」，是「不知道谁授的」。 所以授权操作本身也要留痕，而且要能按时间倒查。 要记的最小集合是四个：谁、给谁、授了什么范围、什么时候。 这四条记全了，就能回答「为什么他能看这一路」——而这正是出事之后第一个要回答的问题。 还有一个容易被忽略的审计点是「查看」：谁在什么时候看了哪一路，也要记。 它不影响功能，只影响「能不能说清」。

四、动手 Demo：一个域树，最多能有几个节点

按「一市五区、每区八所」算节点数，再看树深对可授权范围的影响。

city, district, station = 1, 5, 8
total = city + district + district * station
print("节点数", total)

for depth in (1, 2, 3, 4):
    n, cnt = 1, 0
    for d in range(depth):
        n *= (district if d else 1)
        cnt += n
    print(depth, "层", cnt, "个节点")

实跑输出：

--------------------------------------------------------------------
一个域树，最多能有几个节点
--------------------------------------------------------------------
**分域管理是「按组织架构建一棵树」**：**市局管区局、区局管派出所。**
**树的好处是「权限天然继承」**：**给上级授权，等于给整棵子树授权。**

  1 市 + 5 区 + 40 派出所 = 46 个节点
  深度 3 层

**节点数不多，但权限的组合会快速膨胀**：**每加一层，可授权的范围就多一档。**
  树深         节点数             可授权范围
  --------------------------------------------------
  **1 层**     **1 个节点**       **1 种范围**
  **2 层**     **6 个节点**       **6 种范围**
  **3 层**     **31 个节点**      **31 种范围**
  **4 层**     **156 个节点**     **156 种范围**

**第三列等于第二列**——**因为「每个节点都能单独授权」，范围数就等于节点数。**
**所以「按域授权」的可控粒度，天然等于树的细度。**

**这也带来一个设计问题：树要不要做深**：
  做法                 好处           坏处
  --------------------------------------------------------------
  **树浅（两层）**     **好维护**     **粒度粗，跨区共享难**
  **树深（四层）**     **粒度细**     **节点多，维护成本高**
  **树浅加设备组**     **兼顾**       **两套模型，代码复杂**

**第三行是成熟平台的常见选择**：**树只做到「区」这一级，再往下的例外用设备组补。**
**这样树不会失控，例外也有地方放。**

**还有一个必做的动作是「审计」**：**谁能授权、授给了谁、什么时候授的。**
**权限系统最怕的不是「授错」，是「不知道谁授的」。**
**所以授权操作本身也要留痕，而且要能按时间倒查。**

四十六个节点，三层结构——这个规模对一个区县级项目正好，再深就该考虑设备组了。 树深那张表里「可授权范围等于节点数」这一列最值得记： 它说明「按域授权」的可控粒度天然等于树的细度，想要更细就得加层，或者引入第二种模型。 但加层不是免费的：四层就是一百五十六个节点，界面上的树要展开四次才能看见一台设备。 所以「加层」和「好用」是矛盾的。 最后那段审计的话是本节的重点：「谁授的权」这个问题，平时没人问，出事时第一个问。 而它答不上来的代价，往往比授错权本身更大。

30 秒实验

  1. 算一下：一市五区、每区八所，共几个节点？（46）
  2. 想一下：为什么「可授权范围等于节点数」？
  3. 想一下：什么时候该用「设备组」而不是「加一层树」？

常见误区

  1. 以为「树越深管理越细越好」。 界面展开四次才找到设备，没人愿意用。
  2. 以为「权限继承要真的写记录」。 查的时候带上子树就行。
  3. 以为「审计只是合规摆设」。 「为什么他能看这一路」是出事后的第一个问题。
自测三问（点开对答案） 1. 典型的三层域树是什么结构？ —— **市局—区局—派出所**，一市五区每区八所共四十六个节点。 2. 为什么权限继承实现起来很省事？ —— **不用给每个下级写记录**，**查的时候带上子树即可**。 3. 审计最少要记哪四项？ —— **谁、给谁、授了什么范围、什么时候**。

下一节算总账：三百路的一个项目，四笔账怎么算。

相关笔记