权限设计的4个层次：从菜单到字段，全面拆解myBuilder是如何落地的

摘要：权限设计是商业软件的生命线——布行老板、仓管、财务、销售在同一套系统里干活，谁能看什么、能点什么、能改什么，差一层都可能出事。本文用 myBuilder 的真实权限体系，从菜单、按钮、接口与数据、字段四个层次逐层拆解，讲清「前端管体验、后端管安全」的完整落地方法。

一、先看一个真实场景：为什么权限设计会决定商业软件的生死

做纺织进销存 SaaS 的开发者都遇到过这类需求：

• 老板要看全部单据、成本和利润，但不想让仓管看到进价和毛利
• 仓管要开销售出库单，但提交审核后就不能再改，防止数据被篡改
• 财务要管收入和费用单，但销售和仓管不能碰财务模块
• 跟单员能看到客户信息，但看不到客户的结算价

如果权限设计不到位，结果通常有两种：要么权限太松——一个普通仓管能打开财务报表，商业机密直接泄露；要么权限太死——老板想要一个「只能看、不能改」的视图，开发要写一堆 if/else 判断，每次改需求都牵一发动全身。

myBuilder 的做法是把权限拆成 4 个层次，从粗到细逐层收紧：

一句话理解这套设计的核心思想：前端权限管「体验」，后端权限管「安全」。 前端控制让界面干净、操作顺手；后端控制保证即使有人绕过前端（比如直接调接口），也拿不到没授权的数据。四个层次叠加，才构成完整的权限闭环。

二、基础底座：RBAC 模型，权限体系的「地基」

讲四个层次之前，必须先讲清楚它们的共同底座——角色与用户多对多关联模型（RBAC）。

myBuilder 采用 RBAC 的核心逻辑是：权限不直接分配给用户，而是先分配给角色，再把角色关联给用户。 中间隔了一层「角色」，带来了几个实实在在的好处：

在角色表设计上，myBuilder 有几个值得关注的细节：

• 角色范围分三档：平台可见（只有平台管理员可选）、租户可见（租户管理员可选）、公开（全局唯一，方便把公共功能对外发布）——这套设计天然适配集团化多租户场景
• JSON 配置字段：存储角色个性化的业务扩展字段，角色不只是「权限的集合」，还能携带业务属性
• 刻意不加租户 ID、应用 ID 外键：降低角色表复杂度，避免管理难度指数级上升（设计文档原话：「按需考量即可」）
  
  为什么这是地基？ 因为四个层次的权限（菜单、按钮、数据、字段）全部挂在角色上。角色的设计是否灵活，直接决定上层四个层次能不能撑起来。

三、第 1 层：菜单权限——决定「看得见什么」

3.1 原理：前端权限控制，控制菜单的显示与禁用

菜单权限是四个层次里最外层、最直观的一层。它回答的问题是：一个用户登录后，界面上能看到哪些功能入口？

myBuilder 的做法是在前端做权限控制：控制菜单的显示或禁用。角色没有菜单权限，用户就看不到这个入口；有权限但被禁用，菜单会显示但置灰。

这个设计的价值体现在两个地方：

1. 界面动态适配：根据角色隐藏无关功能，降低用户操作复杂度——仓管的界面没有财务菜单，财务的界面没有仓储菜单，每个人看到的都是「自己的系统」
2. 权限可视化：用户通过角色名称就能理解自己的权限范围（「我是仓管，所以我有开单菜单」），而不是面对一堆抽象的权限代码

3.2 落地案例：纺织进销存里的角色菜单划分

在彩云织布行管家（myBuilder 官方用 40 人天研发的纺织 SaaS 进销存）里，典型的菜单权限划分是这样的：

关键认知：菜单权限只是「第一道门」，它决定入口可见性，但绝不等于数据安全。 如果只做了菜单权限，用户直接拼接口地址依然可能拿到数据——这正是下一层要解决的问题。

四、第 2 层：按钮权限——决定「能点什么」

4.1 原理：控制功能按钮的显示或禁用

进到功能页面之后，第二个问题是：界面上这些按钮，用户能不能点？

myBuilder 的按钮权限同样走前端控制：控制功能按钮（新增、编辑、删除、审核、打印等）的显示或禁用。没有权限的按钮直接隐藏，有权限但受状态约束的按钮置灰。

但按钮权限真正体现功力的，是它和业务状态的结合：

4.2 单据状态锁定：权限跟着单据生命周期走

进销存里最经典的场景：单据提交审核后，就不能再被随意修改。

在 myBuilder 里，这是通过禁用规则配置实现的——单据处于不同状态时，相关按钮和操作自动禁用：

配置方式是可视化的：在设计器里选中按钮，配置「当单据状态 = 已审核 时禁用」，保存即生效，不需要写一行 if/else。

4.3 敏感操作的二次确认：权限的「最后一公里」

按钮权限管的是「能不能做」，但有些操作即使有权限，也需要人的二次确认。myBuilder 提供了一个很实用的框架级能力——接口请求的后台发起确认：

• 示例 1：后端判断申请超过 5 万的资金时，发起监管流程，前端弹窗告诉操作人风险并询问是否确认执行
• 示例 2：数据并发控制，后端校验到数据已被其他用户修改，询问用户是否覆盖

处理原理：前端发起接口调用 → 后端命中业务规则，抛出「确认异常」→ 前端弹窗询问 → 用户确认后以强制提交方式重发请求 → 后端放行执行。整套流程被封装成框架能力，前端代码只需要写一次接口调用。

五、第 3 层：接口与数据权限——决定「拿得到什么」

5.1 为什么前端权限不够？——前端可以被绕过

很多刚接触权限设计的开发者有个误区：觉得菜单和按钮控制住了，权限就做完了。

但事实是：前端的一切控制都只是「体验层」。一个懂技术的人完全可以直接调接口拿到数据。所以 myBuilder 的权限设计里，后端接口访问控制才是真正的安全底线。

5.2 接口访问的三个安全级别

myBuilder 将接口访问划分为三个安全级别：

关键差异在 L2：很多系统做到 L1 就算完了——只要有令牌就能访问所有接口。但 myBuilder 的做法是，令牌只解决「你是谁」，接口授权解决「你能做什么」。两者叠加，才是真正的最小权限。

5.3 系统与系统之间的访问控制：固定令牌 + IP 白名单

进销存 SaaS 很少是孤岛——要对接供应链、财务总账、客户管理系统。系统间调用的权限怎么管？

myBuilder 的做法是固定令牌模式：

1. 为固定令牌绑定具体的用户——这样系统间的调用也有了身份和权限，不是「无主调用」
2. 配合 IP 白名单进一步提高安全性——只允许来自可信服务器的请求

5.4 数据层面的并发控制：数据锁与状态流

「数据权限」除了防外人，还要防自己人打架：工厂里仓管、财务、销售多人同时编辑同一张单据怎么办？

myBuilder 底层自带数据锁与状态流管控：

• 多人同时编辑同一张单据时，数据锁避免覆盖冲突
• 单据从「新增 → 保存 → 提交 → 审核 → 已记账」全流程状态流转内置封装，状态变了，可操作范围随之变化
• 主表 + 明细表（表头 + 多行明细）保存时事务统一处理、操作原子化——不会出现表头保存成功、明细丢失的脏数据

六、第 4 层：字段权限——决定「改得了什么」

6.1 原理：字段级显示/禁用/只读控制

权限的最后一层，也是最细的一层：字段权限。它回答的问题是：同一张单据，不同角色看到的字段内容、可编辑程度是否相同？

myBuilder 通过可视化配置实现字段级控制：

• 字段显隐：某些字段对某些角色直接隐藏（比如「成本价」「利润率」对仓管隐藏）
• 字段只读：某些字段看得到但改不了（比如「制单人」「单据编码」由系统自动回填，不允许手改）
• 显示/禁用表达式：字段的状态可以绑定表达式，按条件动态变化

6.2 财务审计场景下的字段锁定

财务单据对字段权限的要求最苛刻——提交审核后，所有字段必须锁定，杜绝数据篡改，完全贴合财务审计规范。

在 myBuilder 里，通过组件数据源、联动规则配置即可实现：

• 「制单人、制单日期、单据编码」等系统字段直接绑定表达式自动回填，业务人员新增单据时无需手动录入，也天然不可篡改
• 单据提交后，明细表格的可编辑权限通过规则自动关闭，整个单据变成「只读档案」

6.3 字段权限和接口权限的配合

值得注意的是，myBuilder 的字段权限不只是前端体验——后端接口同样遵循令牌 + 接口授权校验。这意味着即使有人绕过前端直接调接口，拿到的数据也受后端权限约束。前端管「显示不显示」，后端管「给不给」，这才是完整的字段级安全。

七、四层联动：一张单据从录入到归档的完整权限旅程

把四个层次串起来看，一张销售出库单的完整生命周期是这样的：

每一层都在「收口」，但收的是不同的口：菜单收「入口」，按钮收「动作」，接口收「数据通道」，字段收「数据内容」。四层叠加，才敢说一个系统能支撑多角色、多租户的长期商业运营。

八、避坑清单（收藏价值所在）

1. 只做前端权限 = 没有权限：菜单、按钮、字段显隐都是前端体验层，可以被绕过。接口授权（L2 级别）才是安全底线，一定不能省。
2. 权限直接挂用户，别挂角色：用户一多就失控。RBAC 中间层是标配，myBuilder 的角色范围（平台/租户/公开）设计天然支持集团化多租户，别自己造轮子。
3. 忘了「状态」这个维度：按钮权限如果只按角色配、不按单据状态配，就会出现「已审核的单据还能改」的严重漏洞。务必把禁用规则和单据状态流绑定。
4. 敏感操作没有二次确认：大额提交、覆盖他人数据这类操作，光有权限还不够。用「接口请求的后台发起确认」加一道人工确认，能拦下大量误操作。
5. 系统间调用不做身份绑定：给对接系统发一个「裸令牌」是最常见的隐患。固定令牌必须绑定用户，再叠加 IP 白名单，否则第三方系统出问题，责任和风险都在你这边。

九、写在最后

权限设计没有玄学，就是把「谁能对什么数据做什么操作」这件事，拆到足够细的粒度，每一层都有明确的控制手段。myBuilder 的四层权限体系（菜单 → 按钮 → 接口与数据 → 字段）之所以能支撑彩云织布行管家这种商业级 SaaS 落地，正是因为每一层都做透了，而且全部是可视化配置——改权限不用写代码，改完立即生效。

这套权限体系是 myBuilder 开箱即用的框架能力，部署完成即拥有，不需要二次开发。

互动提问：你在实际项目中做过权限设计吗？遇到过哪些「权限太松出事」或「权限太死挨骂」的案例？评论区聊聊，我挑典型问题单独写一篇。