主题
角色权限
角色权限页面用来决定：一类人能看到什么菜单、能执行哪些操作、应该被分配给哪些账号。
如果说组织架构解决的是“人属于哪里”，用户管理解决的是“给谁建账号”，那么角色权限解决的就是“这些账号到底能做什么”。
菜单路径
系统管理 → 角色管理
页面定位
角色不是单纯的名字标签，而是系统里的权限包。
你可以把它理解成一套预先配置好的权限方案。比如：
- 老板看全局
- 业务员主要看订单
- 车间员工主要看生产和打包
- 仓管主要看仓库相关页面
然后再把这些角色分配给用户，用户最终拿到的是自己所有角色权限的并集。
这张图想帮你看懂：角色权限不是给页面改名字，而是在先定义一套权限方案，再把它发给具体的人。
这页适合解决什么问题
它更适合处理这些场景：
- 新岗位上线后，要给这类岗位设计一套权限
- 老角色权限太大或太乱，需要重新收口
- 新增了系统菜单，需要补勾给已有角色
- 需要把某个角色批量分配给多人
- 某类账号看不到页面或按钮时，要回头检查角色是否漏配
它不适合替代这些页面：
- 用户管理：负责给具体账号分配角色，不负责设计权限方案本身
- 组织架构：负责部门层级，不负责菜单权限
- 工厂配置：负责业务规则，不负责账号权限
页面整体结构
当前页面由三部分组成：
- 查询区
- 按角色名称、权限字符、状态、创建时间筛选
- 角色列表
- 查看角色状态，并执行新增、编辑、分配用户、删除、导出等操作
- 抽屉操作区
- 新增/编辑角色抽屉
- 分配用户抽屉
查询区可以筛什么
当前角色页支持以下查询条件：
- 角色名称
- 权限字符
- 角色状态
- 创建时间范围
这意味着如果你只是想找“业务员”或“车间员工”这类角色，可以按角色名称查；如果你是排查历史角色或兼容旧命名，也可以按权限字符查。
列表里实际显示什么
当前列表的主要列包括：
- 角色名称
- 角色权限字符串
- 显示顺序
- 角色状态
- 创建时间
- 操作列
这里要特别注意两个现实情况：
- 列表里会显示权限字符串，即使前端新增/编辑抽屉里没有把它开放成单独输入框。
- 数据范围列虽然相关代码还在，但当前页面没有正式展示。
常用操作
新增角色
点击右上角 新增，会打开新增角色抽屉。
当前抽屉实际可维护的字段包括：
- 角色名称
- 显示顺序
- 角色状态
- 菜单权限
- 备注
这里有一个非常关键、也最容易和传统认知不一致的地方：
- 当前前端没有把“权限字符”开放成可手工填写字段
- 权限字符输入框代码已被注释
- 系统会自动同步角色标识与角色名称
所以从当前用户实际操作角度看，更准确的说法不是“手工填写角色名称和权限字符”，而是：
- 你主要维护角色名称
- 系统会同步生成并提交同名的权限字符
菜单权限怎么配
新增角色时，抽屉里会显示菜单权限树。你可以直接勾选该角色应该看到的菜单和相关入口。
当前实现里：
- 新增角色默认状态为启用
- 默认显示顺序为
1 - 菜单树支持父子联动严格模式配置
编辑角色
点击列表行内的 编辑，可以修改已有角色。
编辑时会做两件事：
- 先把当前角色基础信息带入抽屉
- 再去后端拉取这一个角色当前已勾选的菜单权限树
这意味着：
- 角色编辑不只是改名称或状态
- 更重要的是核对这套角色当前到底勾了哪些菜单
使用建议
新增系统菜单或新增模块后，记得回到角色管理里逐个检查关键角色是否已经补勾新菜单。否则用户会出现“明明需要用，但登录后看不到入口”的情况。
启用 / 停用角色
列表中的角色状态支持直接切换，不必先进入编辑抽屉。
- 后端状态修改接口：
但这里有一个重要限制：
- 如果该角色已经分配给用户，就不能直接禁用
对应后端实现：
也就是说，角色状态不是想关就关。真正落地时，往往要先把角色和用户解绑，才能停用。
删除角色
角色支持：
行内删除单个角色
勾选后批量删除多个角色
后端删除接口：
删除前当前系统会检查：
- 是否为超级管理员角色
- 是否仍有用户在使用这个角色
对应后端实现：
- 超级管理员角色保护：
- 已分配用户时禁止删除：
这张图想帮你看懂：角色删除必须先看它是不是受保护角色、是否已经被人实际使用。
分配用户
角色管理里有一个非常实用的能力：从角色侧批量分配用户。
这和用户管理里的“给某个人选角色”不同，它更适合处理：
- 新建一个角色后，要一次性分给一批人
- 想看某个角色当前都分配给了谁
- 想批量收回某个角色的授权
当前实现里，这不是独立页面，而是角色列表中的“分配用户”抽屉。
分配用户抽屉能做什么
当前抽屉支持：
- 按用户名筛选
- 按昵称筛选
- 按手机号筛选
- 按所属部门筛选
- 按创建时间筛选
- 勾选/取消勾选用户
- 一次性提交新增授权和取消授权
这里还有一个实现细节很重要：
- 抽屉不是“左边未分配、右边已分配”的双栏页
- 而是先读取用户总表，再把已分配给这个角色的人预先勾选出来
- 提交时，系统会自动比较差异，分别处理新增和取消授权
数据权限要怎么理解
这一点是旧文档最容易写错的地方。
从后端能力看，角色不仅有菜单权限，还支持数据权限。比如：
- 数据权限范围
- 部门标识清单
- 部门包含下级
对应后端定义可见：
而且前端其实也已经写好了“数据权限抽屉”代码。
但是，当前正式角色页面并没有把这个入口开放出来，相关按钮和抽屉挂载都处于注释状态。
所以当前面向用户的正确口径应该是：
- 系统代码层面支持角色数据权限能力
- 但当前角色管理页面未正式开放这个入口
- 因此本页当前以菜单权限 + 分配用户为主
当前系统的几个关键规则
1）角色名称唯一
新增和编辑角色时，后端会校验角色名称是否重复。
对应后端实现：
2）权限字符唯一
虽然前端没有开放手工填写权限字符，但系统仍然会校验角色标识的唯一性。
对应后端实现：
3）超级管理员角色不能按普通角色操作
当前前后端都做了保护：
前端里 管理员角色 的角色不显示行内操作，状态开关也禁用
后端也会拦截对超级管理员角色的修改、删除等操作
前端保护：、
后端保护：
4）系统内置管理员角色标识符不能被乱占用
后端还会额外保护内置管理员角色标识符，避免普通角色冒用或篡改成系统级管理员标识。
对应后端实现：
5）已分配用户的角色不能禁用，也不能删除
这是非常重要的真实业务规则：
- 角色只要已经分配给用户，就不能直接禁用
- 也不能直接删除
所以如果你操作失败，优先去检查：是不是还有用户正在使用这个角色。
6）修改角色后，相关在线用户会被清理会话
当前后端为了让权限即时生效，会在角色修改成功后，清理关联在线用户的会话。
对应后端实现：
- 编辑后清理在线用户：
这意味着：
- 你改完角色权限后，相关用户可能需要重新登录
- 这不是异常，而是系统为了让新权限立即生效的正常行为
7）分配或取消用户授权时，不允许修改当前登录用户自己的角色关系
后端会拦截这类操作，防止当前登录人把自己关键角色误删或误改。
角色和岗位的区别
很多人第一次配置时，容易把“角色”和“岗位”混在一起。
这张图想帮你看懂：岗位偏组织身份，角色偏系统权限，它们不是一个东西。
更直白一点：
- 岗位：偏“这个人在公司里做什么工作”
- 角色：偏“这个人在系统里能用哪些功能”
一个用户可以有多个角色，因此最终权限通常是多个角色叠加后的结果。
推荐配置顺序
如果你是第一次配置系统，建议按这个顺序做：
这张图想帮你看懂：角色设计最好先成体系，再去发给人，不要边建边乱改。
使用建议
使用建议
- 角色名称尽量写成业务上能看懂的名字，不要只写技术缩写。
- 先按岗位职责设计角色，再去分配给用户，不要每来一个人就临时拼一套权限。
- 同类岗位尽量共用角色，减少后期维护成本。
- 新增菜单后记得回查关键角色是否补勾，这是最常见的漏配来源。
- 碰到看不到菜单、点不了按钮，先查角色，不要先怀疑系统坏了。
- 修改核心角色前先通知相关人员，因为系统可能会让在线用户重新登录以刷新权限。
常见问题
为什么我新增角色时没有看到“权限字符”输入框？
因为当前前端页面没有把这个字段开放给用户单独填写。当前实现会把权限字符随角色名称同步生成并提交。
为什么角色能看到，但不能停用？
大概率是这个角色已经分配给用户了。当前后端会拦截“已分配用户的角色禁用”。
为什么角色删不掉？
优先检查两件事：
- 它是不是超级管理员角色或受保护角色
- 是否还有用户正在使用它
为什么我改完角色后，有人需要重新登录？
因为系统会在角色权限变更后清理相关在线会话，让新权限立即生效。这是正常设计，不是故障。