只要系统进入真实业务，权限就会变复杂。谁能看客户、谁能改订单、谁能导出数据、谁能审批、谁操作过某条记录，这些都关系到管理效率和风险控制。权限设计如果一开始太随意，后面会很难补。
典型架构链路
- 用户 User
- 角色 Role
- 权限 Permission
- 资源 Resource
- 数据范围 Data Scope
- 操作日志 Audit Log
- 审批 / 风控
RBAC：先把用户、角色、权限拆开
用户不应该直接绑定一堆零散权限，而是通过角色获得权限。角色可以是管理员、销售、仓库、财务、项目经理、客户等。
菜单权限不等于操作权限
能看到订单列表，不代表能删除订单；能查看客户，不代表能导出客户。按钮级、接口级权限要和菜单权限分开控制。
数据权限决定能看哪些记录
同样是销售角色，有的人只能看自己的客户，有的人能看本部门，有的人能看全部。数据范围通常需要按本人、部门、门店、项目、客户归属来过滤。
字段权限用于保护敏感信息
手机号、报价、成本、利润、合同附件等字段可能需要脱敏或限制查看。字段权限可以避免低权限角色看到敏感数据。
操作日志要记录关键动作
创建、修改、删除、导出、审批、登录失败、权限变更都应该记录操作人、时间、IP、旧值、新值和业务对象。
审计追踪让系统可复盘
当库存不对、订单异常、客户信息被改时，审计日志能帮助团队快速定位是谁、什么时候、因为什么操作导致变化。
落地前建议确认
- 是否有多个业务角色
- 是否需要限制数据范围
- 是否有敏感字段
- 是否需要追踪修改、删除、导出和审批