RBA C角色定义需以真实业务职能为基础，确保职责清晰、权限收敛、易于维护；应明确角色承担者、日常任务及必需系统功能，按“最小职责闭环”划分粒度，采用“业务域_职能_等级”统一命名，并支持继承与组合。

RBA C角色定义不是列几个职位名称就完事，关键在于让角色真正承载业务职责、支撑权限收敛和后续维护。角色设计质量直接决定整个权限体系是否清晰、安全、可演进。

角色必须对应真实业务职能

避免凭空造词或照搬组织架构头衔。比如“运维工程师”比“技术部人员”更准确，“财务审核员”比“财务组成员”更聚焦操作边界。每个角色应能回答三个问题：谁会担任它？日常做什么？哪些系统功能是其必需？

• 销售代表 → 客户信息查看、线索录入、报价单生成
• 合同管理员 → 合同模板管理、签署流程启动、历史合同归档
• 数据看板运营 → 看板配置、指标口径维护、导出权限开关

角色粒度要兼顾灵活性与可管理性

太粗（如只设“管理员”“普通用户”）导致权限过度开放；太细（如为每个审批节点单独建角色）又带来爆炸式维护成本。建议按“最小职责闭环”划分：

• 一个角色覆盖完成某类业务动作所需的全部权限，不跨域
• 同一业务线内，角色之间有明确上下级或并列关系，例如“初审员”“复核员”“终审员”，而非混用“审核A岗”“审核B岗”
• 对临时性高危操作（如数据库删表），不固化为常驻角色，而是通过审批流程+临时角色授予

角色命名需统一、无歧义、可读性强

命名规则直接影响开发、运维、审计人员的理解效率。推荐采用“业务域_职能_等级”结构，例如：

• hr_employee_basic（HR员工基础信息操作员）
• finance_payment_approver_l2（财务付款二级审批人）
• ops_k8s_cluster_admin（运维K8s集群管理员）

禁用缩写、拼音首字母、带版本号（如v1/v2）或含主观形容词（如“高级”“资深”）的命名，这些都会在交接或审计时引发歧义。

预留继承与组合能力

角色不是孤立存在。设计初期就要考虑复用路径：

• 定义基础角色（如system_readonly），被多个业务角色继承
• 允许用户同时拥有多个角色，例如“研发负责人”可叠加“代码仓库管理员”+“发布审批员”
• 用role_hierarchy字段或auth_item_child表明确父子关系，避免靠人工记忆维护