权限不是把某个菜单藏起来。用户即使看不见入口，也可能通过链接、接口或旧页面访问资源。界面负责告诉用户“能看什么、为什么不能做”，真正的授权必须由服务端在每次请求中执行。
权限不是把某个菜单藏起来。用户即使看不见入口，也可能通过链接、接口或旧页面访问资源。界面负责告诉用户“能看什么、为什么不能做”，真正的授权必须由服务端在每次请求中执行。
01 先把四类权限拆开
复杂B端系统的权限问题，往往来自一个“角色”字段承载了太多含义。更清楚的方式是拆成四层：
| 权限层 | 回答的问题 | 例子 |
|---|---|---|
| 入口与页面 | 用户是否能进入某个模块或页面 | 是否显示“财务管理”菜单 |
| 数据范围 | 进入后能看到哪些记录 | 仅本人、本人部门、负责客户、全部 |
| 操作权限 | 对记录能执行哪些动作 | 新建、编辑、删除、导出、审批 |
| 字段权限 | 同一条记录里哪些字段可见或可改 | 销售可见联系人，财务可见回款信息 |
很多产品只做第一层。结果是菜单看似简洁，进入共享链接后却能看到不该看的数据；或者用户能看见按钮，点击后才得到模糊的“无权限”。
02 RBAC是起点，不一定是终点
RBAC的基本关系是：用户被分配到角色，角色拥有权限。它适合岗位较稳定、规则可归纳的组织，例如销售、销售主管、财务、系统管理员。
但当权限依赖地区、客户归属、金额、项目成员、数据敏感级别或临时状态时，只增加角色会出现“角色膨胀”：华东销售主管、华南销售主管、大客户销售主管、临时代理主管……角色数量越来越多，仍然无法准确表达规则。
这时可以使用混合模型：
- 角色决定基础能力；
- 组织、资源、时间或业务属性决定数据范围；
- 审批和临时授权处理例外；
- 高风险操作再进行二次确认或双人复核。
无论采用哪种模型，都应遵循最小权限和默认拒绝：没有明确授权，就不开放。
03 先做权限矩阵，再画界面
下面是一张简化的CRM权限矩阵：
| 角色 | 客户数据范围 | 编辑客户 | 导出 | 修改负责人 | 审批折扣 |
|---|---|---|---|---|---|
| 销售 | 本人负责 | 是 | 否 | 否 | 否 |
| 销售主管 | 本部门 | 是 | 条件允许 | 是 | 低于阈值 |
| 财务 | 已成交客户的财务字段 | 仅财务字段 | 财务报表 | 否 | 查看结果 |
| 业务负责人 | 全部业务数据 | 是 | 是 | 是 | 高额度审批 |
| 系统管理员 | 配置与审计所需范围 | 不参与业务编辑 | 按策略 | 配置权限 | 不替代业务审批 |
矩阵里不要只写“有/无”。数据范围、条件、状态和例外必须写清。比如“可编辑”需要继续问：只能编辑自己创建的吗？审批后还能改吗？敏感字段是否例外？
04 入口怎么处理：隐藏、禁用还是只读
这三个状态表达的含义不同。
适合隐藏
用户永远不会使用、也不需要知道的模块，例如普通员工不参与系统配置。隐藏可以减少干扰，但不能替代后端鉴权。
适合禁用并解释
用户知道该功能存在，但当前条件不满足，例如“只有完成实名认证后才能导出”。保留按钮并说明原因，可以帮助用户理解下一步。
适合只读
用户需要查看信息，但不应修改，例如财务查看合同、审批人查看已归档申请。只读界面应明确状态，避免看起来像控件失效。
| 场景 | 推荐表现 | 原因 |
|---|---|---|
| 从未授权的系统模块 | 隐藏入口，直接URL仍返回拒绝 | 减少噪音并保持安全边界 |
| 因流程状态暂不可操作 | 显示禁用按钮与原因 | 用户需要知道动作何时可用 |
| 有查看权但无编辑权 | 显示只读内容，隐藏编辑控件 | 保留工作上下文 |
| 请求额外权限 | 展示申请入口、审批人和预计范围 | 让用户有解决路径 |
05 数据权限要从“资源关系”出发
“本人、部门、全部”适合部分组织，但并不能覆盖所有产品。项目制、矩阵组织或外部协作中，数据范围可能来自：
- 记录创建人；
- 当前负责人；
- 项目成员；
- 所属客户与客户团队；
- 组织树和地域；
- 数据敏感级别；
- 合同或任务状态；
- 临时授权的有效时间。
设计时应为用户解释当前视图的范围。列表标题、筛选器或提示可以明确“正在查看华东区全部客户”，避免用户误以为系统只有这些数据。
06 字段权限不要做成“半张神秘表单”
当部分字段不可见时，需要考虑布局和业务含义。完全隐藏敏感字段是合理的，但如果缺失字段会让用户误解记录，则应给出占位说明，例如“该信息仅财务角色可见”。
可编辑字段也要区分：
- 永久可编辑；
- 仅在草稿阶段可编辑；
- 修改后需要重新审批；
- 只能提交变更申请；
- 只能由字段责任人维护。
这些规则应同时出现在字段状态、帮助说明和后端校验中。
07 权限变更后，当前会话怎么办
管理员撤销权限后，已登录用户是否立即失效？已打开页面能否继续保存？导出任务是否应该取消？这些问题常被留到开发阶段才讨论。
高风险权限变更建议明确：
- 何时重新计算权限；
- 缓存多久刷新；
- 长任务以提交时还是执行时权限为准；
- 临时授权何时到期；
- 被撤权用户如何收到通知；
- 变更是否写入审计日志。
08 界面权限与后端授权必须一一对应
前端隐藏按钮只能改善体验。后端需要对每次请求验证权限，并检查具体资源，不应因为用户“进入了页面”就默认后续操作都合法。
测试时至少覆盖：
- 修改请求参数访问他人记录；
- 直接打开未授权链接；
- 低权限用户调用高权限接口；
- 权限撤销后继续使用旧页面；
- 批量操作中混入无权限记录；
- 导出、搜索和统计是否泄露不可见数据；
- 错误信息是否暴露敏感资源存在。
09 管理端怎么设计，才能不把权限配乱
权限管理界面应让管理员回答三个问题：谁、对什么、能做什么。推荐提供：
- 角色说明和适用人群；
- 权限按业务模块分组，而不是按接口名称罗列；
- 高风险权限单独标记；
- 角色变更前的影响预览；
- 直接授权与继承授权的来源；
- 临时权限的到期时间；
- 冲突和过度授权提示；
- 修改记录、操作者和原因。
不要让管理员在几百个复选框中盲选。常见岗位可以使用预设角色，再对少量属性和例外进行配置。
10 一份权限设计交付清单
- 用户、角色、组织和资源关系图；
- 菜单、页面、数据、操作和字段权限矩阵；
- 各角色的关键任务与界面差异；
- 隐藏、禁用、只读和申请权限的使用规则；
- 权限变更、代理、到期和异常流程；
- 前后端权限点映射；
- 审计日志字段和查询方式；
- 安全测试与验收场景。
常见问题
一个用户可以有多个角色吗？
可以，但要明确权限是并集、优先级还是存在互斥。高风险系统还应检查角色组合是否形成职责冲突，例如同一人既发起付款又最终审批。
没权限的按钮应该隐藏还是禁用？
取决于用户是否需要知道功能存在。永久无关的功能可以隐藏；因状态、套餐或流程条件暂不可用的动作，保留并解释更有帮助。安全校验不受界面表现影响。
超级管理员是否应该拥有全部业务权限？
不一定。系统配置权与业务审批权可以分开。技术管理员需要维护系统，并不意味着可以查看所有敏感业务数据或代替业务负责人作出决定。
权限规则由产品、研发还是安全团队负责？
业务负责人定义责任和边界，产品与设计把规则转成任务和界面，研发实现服务端授权，安全与测试验证是否可绕过。没有任何一方能单独完成。
11 让研究和设计真正进入产品决策
链接复制成功
