语之溪
学校业务系统中的权限配置，通常不只是“能不能登录”。用户登录之后，还需要确定能看到哪些菜单、能访问哪些数据、能执行哪些操作，以及当前状态下是否允许继续操作。
低代码平台可以提供用户、角色、菜单和权限等基础能力，但业务系统的权限边界仍然需要结合实际场景设计。
用户、角色和权限不是一回事
用户是具体使用系统的人，角色是对一类职责的抽象，权限则描述允许执行的操作或访问的资源。
用户
-> 绑定角色
-> 获得菜单和功能权限
-> 叠加数据范围
-> 执行业务操作这样做可以避免把每个用户的权限单独配置一遍。用户岗位或职责变化时，调整角色关系通常比逐项修改权限更容易维护。
但角色也不能简单按照部门名称堆出来。一个角色应该对应相对清晰的业务职责，否则角色数量会不断增加，权限边界也会变得难以理解。
菜单权限不等于数据权限
用户能看到某个菜单，不代表可以访问菜单下的所有数据；用户可以打开某个页面，也不代表可以执行新增、编辑、删除和导出等全部操作。
权限至少可以分成几个层次：
- 菜单或页面访问权限；
- 按钮和操作权限；
- 数据范围权限；
- 字段查看或编辑权限；
- 流程节点和状态权限。
例如，某个角色可以查看本部门数据，但不能查看其他部门；可以编辑草稿，却不能修改已经审核通过的内容；可以发起流程，但不能审批自己的申请。
这些是通用权限模型，不对应内部系统的具体角色和数据范围。
权限要和业务状态配合
权限并不是静态的。即使用户拥有编辑权限，记录进入审核状态后，也可能暂时不能修改；退回后可以重新编辑；完成后又恢复只读。
角色权限
+ 记录当前状态
+ 流程节点条件
-> 当前允许的操作因此，判断一个按钮是否显示或是否可用时，不能只看用户有没有某个角色，还要同时判断数据状态和业务规则。
页面层可以隐藏不允许使用的按钮，但服务端仍然需要再次校验。否则用户可能通过直接请求接口绕过页面限制。
低代码平台和代码扩展
低代码平台通常能够配置角色、菜单、按钮和基础数据范围。对于简单的权限需求，这些能力已经足够。
但遇到复杂规则时，可能需要通过表达式、接口或代码扩展完成。例如，数据范围取决于组织层级，审批权限取决于申请人与审核人的关系，或者某些字段只有在特定状态下才能编辑。
标准权限配置
-> 验证是否覆盖业务规则
-> 配置可解决的部分
-> 扩展特殊数据范围或状态判断
-> 前后端一起验证本文只介绍通用处理方式，不展开内部扩展点、角色名称、接口和权限配置。
权限测试不能只测一个账号
权限配置完成后，至少需要准备不同角色和不同状态的数据进行验证。一个账号能够正常打开页面，只能说明其中一条路径可用，不能说明权限体系完整。
测试时可以覆盖：
- 普通用户和管理用户；
- 不同组织或数据范围；
- 草稿、待审核、退回和已完成状态；
- 有权限和无权限的页面入口；
- 直接访问接口和重复提交操作；
- 角色变更后的权限刷新。
如果只测试正常流程，越权、数据串看和状态绕过等问题可能会被遗漏。权限测试的重点，是确认用户既能做应该做的事，也不能做不应该做的事。
权限配置的目标是可理解和可维护
权限系统并不是配置项越多越安全。角色过多、权限命名不清、数据范围相互覆盖，都会增加维护难度。
我会更关注几个问题：这个角色负责什么，能够访问哪些菜单，能够操作哪些状态，数据范围如何确定，角色变化后如何验证。只有这些问题能够说明白，权限配置才不只是平台里的几张表，而是可维护的业务规则。
学校业务系统中的权限设计，最终仍然要回到业务职责。平台提供基础能力，代码可以补充特殊规则，但权限边界需要由需求理解、实现和测试共同确认。
