辽宁省网站建设_网站建设公司_产品经理_seo优化

前言

角色设计是权限系统的基础。很多系统角色设计混乱：权限过大、职责不清、无法审计。这篇给你角色设计的5大原则+角色清单模板。

一、角色设计5大原则

原则1：最小权限原则

角色只拥有完成工作所需的最小权限，不多给。

✓ 正确： - 客服角色：查看订单、编辑订单状态 - 不包含：删除订单、修改价格 ✗ 错误： - 客服角色：订单所有权限（包括删除、改价）

原则2：职责分离原则

关键操作需要多个角色配合，避免一人独揽。

✓ 正确： - 财务申请：财务专员 - 财务审批：财务经理 - 财务支付：出纳 ✗ 错误： - 财务所有操作：财务角色（一人可以申请、审批、支付）

原则3：可审计原则

所有操作必须可追溯：谁、何时、做了什么。

✓ 正确： - 记录操作日志：用户ID、角色、操作、时间、结果 ✗ 错误： - 不记录日志，或只记录操作不记录角色

原则4：角色分层原则

角色分为系统角色和业务角色，避免混淆。

✓ 正确： - 系统角色：超级管理员、管理员 - 业务角色：销售、客服、财务 ✗ 错误： - 所有角色混在一起，没有分层

原则5：角色可组合原则

一个用户可以拥有多个角色，权限取并集。

✓ 正确： - 用户A：销售 + 销售经理 - 权限：销售权限 + 销售经理权限 ✗ 错误： - 一个用户只能有一个角色

二、角色设计步骤

步骤1：识别业务角色

根据业务需求，识别系统中的所有角色。

识别方法： 1. 梳理业务流程，找出所有参与者 2. 分析每个参与者的职责和权限需求 3. 合并相似角色，避免角色过多 示例：电商系统 - 买家：购买商品 - 卖家：销售商品、管理店铺 - 客服：处理售后、处理投诉 - 运营：管理商品、管理活动 - 管理员：系统管理、数据管理

步骤2：定义角色权限

为每个角色定义具体的功能权限和数据权限。

权限定义方法： 1. 列出所有功能模块 2. 为每个模块定义操作（查看、新增、编辑、删除） 3. 为每个角色分配权限 4. 定义数据权限（能看哪些数据） 示例：销售角色 功能权限： - 客户管理：查看（自己的）、新增、编辑（自己的） - 销售机会：查看（自己的）、新增、编辑（自己的） - 合同管理：查看（自己的） 数据权限： - 客户：owner_id = 当前用户id - 销售机会：owner_id = 当前用户id 禁止权限： - 删除客户 - 修改合同金额 - 查看其他人的客户

步骤3：设计角色层级

将角色分为系统角色和业务角色，建立角色层级关系。

角色层级设计： 系统角色（平台级）： - 超级管理员：系统所有权限 - 管理员：系统管理权限（除用户管理） 业务角色（业务级）： - 销售：客户管理、销售机会管理 - 销售经理：销售权限 + 团队管理权限 - 客服：售后处理、投诉处理 - 客服主管：客服权限 + 团队管理权限 角色继承： - 销售经理继承销售的所有权限 - 客服主管继承客服的所有权限

步骤4：设计角色组合

支持一个用户拥有多个角色，权限取并集。

角色组合示例： 用户A：销售 + 销售经理 权限：销售权限 + 销售经理权限（并集） 用户B：客服 + 客服主管 权限：客服权限 + 客服主管权限（并集） 用户C：销售 + 客服 权限：销售权限 + 客服权限（并集）

三、角色清单模板

完整角色清单模板

角色名称：销售 角色代码：SALES 角色描述：负责客户开发和销售机会跟进 角色类型：业务角色 上级角色：销售经理 功能权限： - 客户管理： * 查看：自己的客户 * 新增：是 * 编辑：自己的客户 * 删除：否 - 销售机会： * 查看：自己的销售机会 * 新增：是 * 编辑：自己的销售机会 * 删除：否 - 合同管理： * 查看：自己的合同 * 新增：否 * 编辑：否 * 删除：否 数据权限： - 客户：owner_id = 当前用户id - 销售机会：owner_id = 当前用户id - 合同：buyer_id = 当前用户id 禁止权限： - 删除客户 - 修改合同金额 - 查看其他人的客户 - 导出客户数据 审计要求： - 记录所有客户编辑操作 - 记录销售机会状态变更 - 记录合同查看操作 使用场景： - 新入职的销售人员 - 需要管理自己客户的销售

角色权限矩阵模板

角色权限矩阵（示例）： | 功能模块 | 操作 | 销售 | 销售经理 | 客服 | 管理员 | |---------|------|------|---------|------|--------| | 客户管理 | 查看 | 自己的 | 团队的 | 所有 | 所有 | | 客户管理 | 新增 | 是 | 是 | 否 | 是 | | 客户管理 | 编辑 | 自己的 | 团队的 | 否 | 是 | | 客户管理 | 删除 | 否 | 否 | 否 | 是 | | 销售机会 | 查看 | 自己的 | 团队的 | 否 | 所有 | | 销售机会 | 新增 | 是 | 是 | 否 | 是 | | 销售机会 | 编辑 | 自己的 | 团队的 | 否 | 是 | | 合同管理 | 查看 | 自己的 | 团队的 | 否 | 所有 | | 合同管理 | 新增 | 否 | 是 | 否 | 是 | | 合同管理 | 编辑 | 否 | 否 | 否 | 是 | | 系统设置 | 查看 | 否 | 否 | 否 | 是 | | 系统设置 | 编辑 | 否 | 否 | 否 | 是 |

四、实际案例

案例1：电商平台角色设计

业务场景：电商平台需要管理买家、卖家、平台运营等不同角色。

角色设计： 1. 系统角色： - 超级管理员：系统所有权限 - 平台管理员：平台管理权限（除用户管理） 2. 业务角色： - 买家： * 功能权限：浏览商品、下单、查看订单、申请退款 * 数据权限：只能看自己的订单 * 禁止权限：管理商品、管理店铺 - 卖家： * 功能权限：管理商品、管理订单、管理店铺、查看数据 * 数据权限：只能看自己店铺的数据 * 禁止权限：管理其他店铺、修改平台设置 - 平台运营： * 功能权限：管理商品审核、管理活动、查看平台数据 * 数据权限：能看所有数据（但敏感字段脱敏） * 禁止权限：修改系统设置、删除用户 3. 角色组合： - 一个用户可以是买家+卖家（既是买家也是卖家） - 权限取并集

案例2：CRM系统角色设计

业务场景：CRM系统需要管理销售、客服、财务等不同角色。

角色设计： 1. 系统角色： - 超级管理员：系统所有权限 - 系统管理员：系统管理权限 2. 业务角色： - 销售： * 功能权限：客户管理、销售机会管理、合同查看 * 数据权限：只能看自己的客户和销售机会 * 禁止权限：删除客户、修改合同金额 - 销售经理： * 功能权限：销售权限 + 团队管理、数据统计 * 数据权限：能看团队的客户和销售机会 * 禁止权限：删除客户、修改合同金额 - 客服： * 功能权限：售后处理、投诉处理、客户查看 * 数据权限：能看所有客户（但敏感字段脱敏） * 禁止权限：编辑客户、删除客户 - 财务： * 功能权限：合同审核、发票管理、财务统计 * 数据权限：能看所有合同和财务数据 * 禁止权限：修改合同、删除合同 3. 角色层级： - 销售经理继承销售的所有权限 - 销售总监继承销售经理的所有权限

案例3：在线教育平台角色设计

业务场景：在线教育平台需要管理学生、老师、机构管理员等角色。

角色设计： 1. 系统角色： - 平台管理员：平台所有权限 - 平台运营：平台运营权限 2. 业务角色： - 学生： * 功能权限：选课、学习、考试、查看成绩 * 数据权限：只能看自己的学习记录和成绩 * 禁止权限：管理课程、管理老师 - 老师： * 功能权限：课程管理、学生管理、作业批改、成绩录入 * 数据权限：只能看自己课程的学生数据 * 禁止权限：管理其他老师的课程、修改平台设置 - 机构管理员： * 功能权限：机构管理、老师管理、学生管理、数据统计 * 数据权限：能看本机构的所有数据 * 禁止权限：管理其他机构、修改平台设置 3. 角色组合： - 一个用户可以是学生+老师（既是学生也是老师） - 权限取并集

五、常见反模式

反模式1：超级角色

问题：一个角色拥有所有权限，违反最小权限原则。

❌ 错误示例： 角色：管理员 权限：所有权限（包括用户管理、系统设置、业务操作等） 问题： - 权限过大，容易误操作 - 无法区分不同管理员的职责 - 审计困难，不知道是谁操作了什么 ✅ 正确做法： 角色拆分： - 系统管理员：系统设置、用户管理 - 业务管理员：业务管理、数据统计 - 运营管理员：内容管理、活动管理

反模式2：权限过细

问题：每个按钮、每个字段都是一个权限，导致权限管理复杂。

❌ 错误示例： 权限列表： - 客户列表-查看按钮 - 客户列表-新增按钮 - 客户列表-编辑按钮 - 客户详情-查看按钮 - 客户详情-编辑按钮 ...（几百个权限） 问题： - 权限过多，难以管理 - 配置复杂，容易出错 - 性能问题，权限检查慢 ✅ 正确做法： 按功能模块划分： - 客户管理：查看、新增、编辑、删除 - 销售机会管理：查看、新增、编辑、删除 - 合同管理：查看、新增、编辑、删除

反模式3：角色过多

问题：几十个角色，难以管理和维护。

❌ 错误示例： 角色列表： - 销售-初级 - 销售-中级 - 销售-高级 - 销售-资深 - 销售-专家 - 销售经理-初级 - 销售经理-中级 ...（几十个角色） 问题： - 角色过多，难以管理 - 权限配置复杂 - 用户角色分配困难 ✅ 正确做法： 合并相似角色： - 销售：统一销售角色，通过数据权限区分级别 - 销售经理：统一销售经理角色 - 销售总监：统一销售总监角色

反模式4：硬编码角色

问题：代码里写死角色名称，难以扩展和维护。

❌ 错误示例： 代码中硬编码： if (user.role === '销售') { // 销售权限 } else if (user.role === '销售经理') { // 销售经理权限 } 问题： - 新增角色需要修改代码 - 角色名称变更需要修改代码 - 难以维护和扩展 ✅ 正确做法： 角色配置化： 配置文件（roles.yaml）： roles: sales: name: 销售 permissions: [customer.view, customer.create, ...] sales_manager: name: 销售经理 permissions: [sales.*, team.manage, ...]

反模式5：角色和岗位混淆

问题：将组织架构的岗位直接作为角色，导致权限混乱。

❌ 错误示例： 角色列表： - 销售经理-北京 - 销售经理-上海 - 销售经理-广州 ...（每个城市一个角色） 问题： - 角色过多，难以管理 - 权限配置重复 - 人员调动需要修改角色 ✅ 正确做法： 角色和岗位分离： - 角色：销售经理（权限概念） - 岗位：销售经理-北京（组织架构概念） - 数据权限：通过team_id、department_id等字段控制

反模式6：角色权限不清晰

问题：角色权限定义不清晰，导致权限配置错误。

❌ 错误示例： 角色：销售 权限：客户管理（不明确是查看、新增、编辑还是删除） 问题： - 权限不明确，容易配置错误 - 开发人员理解困难 - 测试人员无法验证 ✅ 正确做法： 权限明确定义： 角色：销售 权限： - 客户管理：查看（自己的）、新增、编辑（自己的） - 禁止权限：删除客户、查看其他人的客户

六、最佳实践

实践1：角色数量控制

建议角色数量控制在10个以内，超过10个说明角色划分过细。

角色数量建议： - 系统角色：2-3个（超级管理员、管理员） - 业务角色：5-7个（根据业务模块划分） - 总计：不超过10个 如果角色过多： - 合并相似角色 - 通过数据权限区分级别 - 使用角色组合代替细分角色

实践2：角色命名规范

角色命名要清晰、统一，便于理解和维护。

命名规范： - 使用业务术语，不要使用技术术语 - 名称要简洁，不超过10个字 - 统一命名格式，如：业务角色-级别 示例： ✓ 正确：销售、销售经理、客服、客服主管 ✗ 错误：SALES、SALES_MANAGER、CUSTOMER_SERVICE

实践3：角色权限文档化

将角色权限文档化，便于开发、测试和维护。

文档内容： - 角色名称、代码、描述 - 功能权限列表 - 数据权限规则 - 禁止权限列表 - 使用场景 - 审计要求

实践4：角色权限可配置

将角色权限配置化，不要硬编码在代码中。

配置化方式： - 使用配置文件（YAML、JSON） - 使用数据库存储 - 提供管理界面配置 优势： - 新增角色不需要修改代码 - 权限变更不需要发版 - 便于维护和扩展

实践5：角色权限测试

为每个角色编写测试用例，验证权限是否正确。

测试用例： - 功能权限测试：验证每个功能是否按权限控制 - 数据权限测试：验证数据访问是否按权限过滤 - 越权测试：验证无权限操作是否被拒绝 - 角色组合测试：验证多角色权限是否正确合并

七、FAQ

Q1：角色太多怎么办？

答：建议控制在10个以内。超过10个说明角色划分过细，需要合并。

合并方法：

• 合并相似角色：将功能相似的角色合并为一个
• 使用数据权限：通过数据权限区分级别，而不是创建多个角色
• 使用角色组合：通过角色组合实现复杂权限，而不是创建新角色

示例：

❌ 错误：创建多个角色 - 销售-初级 - 销售-中级 - 销售-高级 ✅ 正确：使用数据权限区分 - 销售角色（统一） - 通过数据权限控制：初级只能看自己的，高级能看团队的

Q2：角色和岗位的区别？

答：岗位是组织架构概念（如：销售经理），角色是权限概念（如：销售管理角色）。一个岗位可以对应多个角色。

区别：

• 岗位：组织架构中的职位，如销售经理、客服主管
• 角色：权限系统中的权限集合，如销售管理角色、客服管理角色

关系：

• 一个岗位可以对应一个或多个角色
• 一个角色可以被多个岗位使用
• 岗位变更不影响角色，只需要重新分配角色

示例： 岗位：销售经理-北京 角色：销售经理角色（权限概念） 岗位：销售经理-上海 角色：销售经理角色（同一个角色） 岗位：销售经理-技术部 角色：销售经理角色 + 技术管理角色（多个角色）

Q3：角色权限怎么设计？

答：根据业务需求，按功能模块划分权限，遵循最小权限原则。

设计步骤：

• 步骤1：梳理所有功能模块
• 步骤2：为每个模块定义操作（查看、新增、编辑、删除）
• 步骤3：为每个角色分配权限
• 步骤4：定义数据权限（能看哪些数据）

设计原则：

• 最小权限：只给完成工作所需的最小权限
• 职责分离：关键操作需要多个角色配合
• 可审计：所有操作必须可追溯

Q4：角色可以组合吗？

答：可以。一个用户可以拥有多个角色，权限取并集。

组合方式：

• 权限并集：多个角色的权限合并，取并集
• 数据权限：数据权限取最宽松的（能看更多数据）
• 禁止权限：只要有一个角色禁止，就禁止

示例： 用户A：销售角色 + 销售经理角色 权限： - 销售权限：客户管理（自己的）、销售机会管理（自己的） - 销售经理权限：客户管理（团队的）、销售机会管理（团队的）、团队管理 合并后： - 客户管理：团队的（取更宽松的） - 销售机会管理：团队的（取更宽松的） - 团队管理：是（销售经理权限）

Q5：角色权限怎么测试？

答：为每个角色创建测试账号，验证权限是否正确。

测试方法：

• 功能权限测试：验证每个功能是否按权限控制
• 数据权限测试：验证数据访问是否按权限过滤
• 越权测试：验证无权限操作是否被拒绝
• 角色组合测试：验证多角色权限是否正确合并

测试工具：

• 使用Postman、JMeter等工具测试接口
• 使用不同角色的测试账号
• 检查接口返回的数据是否符合权限规则

Q6：角色权限变更怎么办？

答：如果角色权限配置化，可以直接修改配置，不需要修改代码。

变更流程：

• 权限变更申请：业务方提出权限变更需求
• 权限评估：评估变更影响和风险
• 权限配置：修改权限配置（配置文件或数据库）
• 权限测试：测试变更后的权限是否正确
• 权限发布：发布权限变更
• 权限审计：记录权限变更日志

注意事项：

• 权限变更要谨慎，避免权限过大或过小
• 权限变更要通知相关用户
• 权限变更要记录日志，便于追溯

工具入口

生成角色设计思维导图