平台管理看着是「用户、角色、权限」，实际最难的是「数据范围」。 「能不能点播」脱离了「哪几路」就没有意义。 国内平台最常用的办法是「按编号前缀授权」——简单、和级联天然对齐。
上一节把设备接进来了，这一节讲「谁能看」。 权限设计错了，后面每一次加功能都要返工，因为「范围」这件事会渗透到每个接口里。
一、四种角色的实质差别
管理员看全部、能改；运维看全部、只读；值班只看本域、能点播和转云台； 访客只看指定几路。 四行的差别其实只有两个维度：「能看哪些设备」和「能做什么操作」。 前者是数据范围，后者是功能权限。 很多平台只做了后者，结果就是「所有人登录进去都看到一万路」，再用起来就乱了。 所以设计的第一步不是列操作，是定义「范围」怎么表达。
二、按编号前缀授权的妙处
国标编号前八位是中心编码，天然就是「域」。
所以「给用户挂一个前缀，凡是以它开头的设备都可见」这种做法，不用建表、不用维护关系、
和级联天然对齐。
这个做法在国内平台里非常普遍，因为它的实现成本几乎为零：
一条 SQL 的 like '34020000%' 就够了。
代价是「跨域共享」很难做：A 区的人要看 B 区的三路，前缀就表达不了。
这时才需要「设备组」这第二套模型。
所以成熟平台通常是「两套并存」：前缀管大范围，设备组管例外。
三、角色是为了「不用逐项勾」
算一下组合数就知道为什么需要角色：六种操作乘五种设备范围，就是三十种组合。 如果每个用户都逐项勾，管理员会疯。 四个角色模板把三十种组合压成四条规则， 这才是「角色」存在的理由——不是为了分类好看，是为了少勾。 但角色不能太细：角色一多，组合就回来了。 经验是「角色数不超过用户数的十分之一」，超过就说明设计跑偏了。 还有一个必须做的功能是「操作留痕」：谁在什么时候看了哪一路、转没转云台。 这不是合规要求，是「出了事能说清」的要求。 很多项目上线时不做，出事时补不上。
四、动手 Demo：权限不是「给不给」，是「能看哪几路」
列四种角色的范围和操作，再算「组合数 vs 角色数」这笔账。
acts, devs, roles = 6, 5, 4
print("组合数", acts * devs)
print("角色数", roles)
print("压缩比 %.1f 倍" % (acts * devs / float(roles)))
实跑输出：
--------------------------------------------------------------------
权限不是「给不给」，是「能看哪几路」
--------------------------------------------------------------------
**平台管理看着是「用户、角色、权限」三件事，实际最难的是「数据范围」。**
**因为「能不能点播」这个权限，脱离了「哪几路」就没有意义。**
角色 设备范围 媒体权限 其他
---------------------------------------------------------------------
**管理员** **全部** **全部** **全部**
**运维** **全部** **只读** **看日志**
**值班** **本域** **点播＋云台** **不能改配置**
**访客** **指定几路** **只看** **不能云台**
**四行里第三行最需要设计**：**「本域」这个范围怎么表达？**
**国标的编号里前八位就是中心编码，天然可以当「域」用。**
**所以「按编号前缀授权」是国内平台最常用的做法**：**给用户挂一个前缀，凡是以它开头的设备都可见。**
**简单、不用额外建表、和级联天然对齐。**
**代价是「跨域共享」很难做**：**A 区的人要看 B 区的三路，前缀授权就表达不了。**
**这时才需要「设备组」这种第二套模型。**
**权限组合数算一下就知道为什么要「角色」而不是「逐项勾」**：
6 种操作 × 5 种设备范围 = 30 种组合
再加 4 个角色模板 → 实际只需维护 4 条规则
**三十种组合压成四个模板，这才是「角色」存在的理由**——**不是为了分类好看，是为了让人不用逐项勾。**
**最后一个容易忽略的点是「操作留痕」**：**谁在什么时候看了哪一路、转了云台，都要记。**
**这不是合规要求，是「出了事能说清」的要求。**
**很多项目上线时不做，出事时补不上。**
三十种组合压成四条规则，压缩七倍多——这就是角色的全部价值：让管理员不用逐项勾。 但「压缩比」不是越大越好：压得太狠，就会出现「某个用户什么都不够用」的情况， 然后被迫加例外，例外一多，角色就白设计了。 那张角色表里第三行最考验设计：「本域」怎么表达？ 答案是「编号前缀」，因为国标编号天生带域信息。 最后那句「操作留痕」是本节最容易被跳过的一条：它不影响功能，只影响「出事时能不能说清」。 而这种事一年可能只发生一次，但那一次很要命。
30 秒实验
- 算一下：6 种操作 × 5 种范围 = 多少组合？（30）
- 想一下：为什么「按编号前缀授权」实现成本几乎为零？
- 想一下：什么时候必须用「设备组」？（跨域共享）
常见误区
- 以为「权限就是给不给某个按钮」。 数据范围比功能权限更关键。
- 以为「角色越多越灵活」。 角色一多组合就回来了。
- 以为「操作留痕是合规摆设」。 它是「出事能说清」的唯一依据。
自测三问（点开对答案）
1. 权限设计里的两个维度是什么？ —— **能看哪些设备（数据范围）和能做什么操作（功能权限）**。 2. 「按编号前缀授权」的代价是什么？ —— **跨域共享很难做**，需要第二套「设备组」模型。 3. 为什么必须做操作留痕？ —— **出了事要能说清谁看了什么、做了什么**。下一节换一套软件：EasyGBS 是单进程的，配置和拆分方式都不一样。
- ☐ （本节完，下一节 11.03.01 运行软件）