只要系统进入真实业务，权限就会变复杂。谁能看客户、谁能改订单、谁能导出数据、谁能审批、谁操作过某条记录，这些都关系到管理效率和风险控制。权限设计如果一开始太随意，后面会很难补。
典型架构链路
- 用户 User
- 角色 Role
- 权限 Permission
- 资源 Resource
- 数据范围 Data Scope
- 操作日志 Audit Log
- 审批 / 风控
RBAC：先把用户、角色、权限拆开
用户不应该直接绑定一堆零散权限，而是通过角色获得权限。角色可以是管理员、销售、仓库、财务、项目经理、客户等。
菜单权限不等于操作权限
能看到订单列表，不代表能删除订单；能查看客户，不代表能导出客户。按钮级、接口级权限要和菜单权限分开控制。
数据权限决定能看哪些记录
同样是销售角色，有的人只能看自己的客户，有的人能看本部门，有的人能看全部。数据范围通常需要按本人、部门、门店、项目、客户归属来过滤。
字段权限用于保护敏感信息
手机号、报价、成本、利润、合同附件等字段可能需要脱敏或限制查看。字段权限可以避免低权限角色看到敏感数据。
操作日志要记录关键动作
创建、修改、删除、导出、审批、登录失败、权限变更都应该记录操作人、时间、IP、旧值、新值和业务对象。
审计追踪让系统可复盘
当库存不对、订单异常、客户信息被改时，审计日志能帮助团队快速定位是谁、什么时候、因为什么操作导致变化。
脱敏项目复盘：多部门合同与订单系统的权限设计
权限系统不是给菜单打几个勾。一类合同订单项目同时有销售、交付、财务、区域负责人和外部协作方：销售能看自己的客户，负责人能看区域数据，财务能看金额但不应修改交付，临时接替人员还需要有期限的授权。权限一旦模糊，轻则工作被阻塞，重则发生数据泄露。
业务与产品形态
先按业务动作梳理查看、创建、修改、提交、审批、导出和作废，再定义本人、团队、部门、区域和全局等数据范围。后台提供角色模板、成员授权、临时委托和访问复核；普通用户在任务页只看到自己能处理的记录，不必理解复杂权限配置。
技术解决方案
功能权限使用 RBAC 管理，数据范围通过策略条件附加到查询，敏感字段再做独立掩码与导出控制。服务端对每个业务用例统一鉴权，不能依赖前端隐藏按钮；权限缓存带版本号，组织或授权变化时主动失效。审计日志记录主体、动作、对象、时间、来源、结果及关键字段前后值，并与普通业务日志分开保存。
难点设计
组织调整、跨部门项目、人员离职、临时代理和批量导出最容易出现漏洞。授权必须有生效与失效时间，离职流程主动回收令牌和权限；跨部门访问通过项目成员关系显式授予，不能靠共享账号。审计记录采用追加写入并限制删除，敏感数据只保存必要摘要，避免日志本身成为泄露源。
用户体验
无权限时说明缺少哪类授权和申请入口，不返回模糊的系统错误；审批人能看到权限申请原因、范围和期限。管理员用“某人能看到哪些客户、为什么能看到”反向检查策略，并定期收到长期未使用和即将过期权限清单。
产品效果与验收
测试使用角色与数据范围矩阵，既验证允许路径，也验证越权、横向访问、批量接口和导出。指标包括越权请求拦截、权限申请处理时间、离职回收时效、审计定位时间和季度访问复核完成率。权限系统的目标是在不阻碍正常协作的前提下，使每次敏感访问都能解释、限制和追溯。
权限系统的目标不是隐藏按钮，而是守住业务边界
前端不显示“删除”只能改善体验，真正的权限判断必须发生在每一个后端入口。用户可能直接调用 API，也可能通过导出、批量任务和移动端访问同一份数据。我们会先建立“角色—资源—动作—数据范围”的权限矩阵，再让接口层使用统一授权组件，避免每个开发者用不同条件判断。
RBAC 解决职责，数据范围解决归属
管理员、销售、仓库等角色适合 RBAC，但“销售只能看自己的客户”“区域经理能看本区域”属于属性和关系条件。真实系统经常采用 RBAC 加数据范围：角色决定能否执行动作，组织、归属人、项目成员和记录状态决定能对哪些数据执行。过滤条件必须进入查询语句，不能先查出全部数据再在应用层删除。
权限变化需要处理缓存和存量会话
为了性能，角色和菜单常被缓存，但员工调岗、离职或权限收回时，旧 Token 和缓存可能继续生效。我们会给权限配置增加版本号，重要变更主动使会话失效；高风险操作再次读取实时权限。批量导出、后台任务也要记录发起人的权限上下文，不能由一个拥有超级权限的任务进程无条件执行。
审计日志应不可随业务记录一起修改
审计内容至少包括操作者、时间、请求 ID、业务对象、动作、结果和关键字段前后值。密码、令牌和完整身份证号不能进入日志，联系方式按需要脱敏。审计表与普通业务表分开授权，只追加不覆盖；删除业务记录时仍保留必要的审计引用。对于审批、退款和权限变更，还应记录原因及关联单据。
超级权限也需要边界
生产环境不应存在长期共享的万能账号。紧急处理可以使用临时提权机制，要求申请原因、限定时间并完整审计；危险操作增加二次确认或双人审批。我们还会定期导出角色权限差异，检查长期未使用账号、孤立角色和权限膨胀。权限设计不是一次配置，而是跟组织变化一起维护的系统能力。
权限校验要落在后端的哪几层
身份、角色与权限是三件不同的事
认证层确认当前 principal，授权层再根据 user_role、role_permission 判断能否执行某个 action。后端接口按权限编码校验，不能依赖前端菜单是否显示。角色或员工状态变更后要让会话与权限缓存及时失效，离职账号立即停用；高风险操作可要求近期重新认证，避免长期登录态被借用。
数据范围必须进入查询条件
“可以查看订单”不代表可以查看全部订单。服务端根据租户、组织、负责人和协作关系生成数据范围谓词，并在仓储查询层统一应用。用户传入 customer_id 或 order_id 时仍要验证对象归属，不能只在列表接口做过滤、详情接口直接按主键返回。多租户系统还应在表结构和唯一约束中包含 tenant_id。
字段脱敏与导出要单独授权
销售可能需要客户电话但不能看到成本，财务能看金额却不一定能导出全部客户。序列化响应时按字段策略屏蔽或脱敏，导出、批量下载和复制敏感信息设置独立权限，并限制数量与频率。前端隐藏列只是体验优化，真正的字段控制必须在 API 输出阶段完成。
审计日志不能和普通调试日志混为一谈
审计记录至少包含 operator_id、action、resource_type、resource_id、before、after、request_id、IP 与时间，采用追加写入并限制删除权限。登录失败、权限拒绝、导出、审批和配置修改都应留痕。紧急越权账号要有过期时间和使用原因；日志设置保留周期与访问权限，既能追责，也避免审计库本身成为数据泄漏入口。
落地前建议确认
- 是否有多个业务角色
- 是否需要限制数据范围
- 是否有敏感字段
- 是否需要追踪修改、删除、导出和审批