权限不是一个 role_id
业务后台的权限经常从一个 role_id 开始，最后变成一堆 if 判断。原因是系统把三件事混在了一起：用户能不能看到某个菜单，能不能点击某个按钮，能不能访问某个范围的数据。
这三类权限的变化频率不同，风险也不同。菜单权限影响入口，按钮权限影响动作，数据范围影响信息边界。越是涉及客户、订单、财务、导出和改派，越不能简单混用。
- 菜单权限决定页面入口。
- 按钮权限决定新增、编辑、删除、审核、导出等动作。
- 数据范围决定本人、团队、部门、全部等可见范围。
- 敏感字段可以独立做字段级权限。
权限树如何建模
一种可维护的做法是把权限节点抽象为资源树。菜单是资源，按钮也是资源，数据范围是角色或策略绑定的约束。前端根据权限树渲染入口和按钮，后端在接口层再次校验，不能只依赖前端隐藏。
对于 CRM，导出、改派、财务字段、订单审核、客户回捞都应该是独立权限点。否则一个普通编辑权限很容易被扩展成过大的能力。
- 资源节点需要 code、name、type、parent_id。
- 角色绑定资源节点，用户通过角色获得权限。
- 数据范围不要硬编码在菜单节点里。
- 接口必须做服务端鉴权。
审计和排障
权限系统必须能解释“为什么这个人看到了这条数据”。没有审计能力，权限问题就会变成猜谜。至少要记录角色变更、资源变更、关键动作和导出行为。
当业务开始出现组织架构调整、临时授权、跨团队协作时，审计会成为系统可信度的一部分。
- 记录谁给谁分配了什么角色。
- 记录敏感动作的操作者、对象、时间和来源。
- 支持查看用户最终权限快照。
- 临时授权要有过期时间。
知识库中的三层权限模型
知识库把 CRM 权限拆成菜单权限、按钮/动作权限、数据范围权限三层。这个拆分很关键，因为后台系统里的“能看页面”和“能做动作”不是一回事，“能操作自己的数据”和“能操作全部数据”也不是一回事。
菜单权限解决入口，按钮权限解决动作，数据范围解决边界。三者组合之后，才能表达真实岗位差异。
- 菜单模块：客户管理、订单管理、系统设置、报表中心。
- 操作按钮：新增、编辑、删除、导入、导出、审核、分配、改派。
- 数据范围：本人、团队、部门、全部、指定客户池。
- 字段权限：佣金、返佣、垫付费用等敏感字段单独控制。
表结构如何支撑权限
知识库中的 CRM 数据库设计建议复用权限分组、权限点、角色、用户角色绑定、数据权限分组和权限变更日志。公开表达时不需要暴露具体业务细节，但模型本身很通用。
一个可维护的权限系统通常包含：权限分组表、权限点表、角色表、角色权限关系表、用户角色关系表、数据权限表、组织/员工表，以及操作审计日志。
- permission_group 组织权限树。
- permission 存储具体路由、按钮或动作 code。
- role 与 role_permission_relation 负责角色授权。
- data_permission 支撑团队、部门、客户池等范围。
敏感权限必须拆出来
知识库里反复强调，导出、改派、回捞、订单审核、财务字段、批量操作、权限配置不能依附普通查看权限。原因很简单：这些动作要么影响数据外流，要么改变客户归属，要么影响资金口径，要么改变系统授权本身。
敏感权限的拆分不是增加复杂度，而是给风险单独装开关。
- 导出权限单独拆分，并记录导出人、条件、数量。
- 改派和回捞要记录原归属、新归属和原因。
- 财务字段可以做到字段级可见。
- 批量权限设置必须有操作日志。
权限排障：回答为什么
权限问题最难的不是控制，而是解释。当用户问“为什么我看不到这个客户”或“为什么他能导出”，系统要能回答：他有哪些角色，这些角色绑定了哪些权限，数据范围如何计算，是否有临时授权，是否被组织关系限制。
因此权限系统最好提供用户最终权限快照。这个快照不一定给所有人看，但运维、管理员和审计需要。
- 展示用户角色列表。
- 展示最终菜单和按钮权限。
- 展示数据范围来源。
- 展示最近权限变更日志。