权限系统的设计思考
一个管理系统一般需要附带一套权限系统，来控制什么样的人可以访问什么资源。如果你的系统是一个网站后台，如公司的 OA 系统，那么权限系统的设计应该在前后端分别设计。
前端权限，主要来控制页面是否可访问，页面上组件元素是否显示、是否可点击、可编辑、可输入等。根据颗粒度不同：
- 路由（或页面）权限
- 页面组件权限
后端权限，主要来控制 API 是否可访问，在细化到底层，API 对应的数据库的增、删、查、改。根据颗粒度不同：
- Restful API 权限
- 数据权限
对于数据权限，如果我们以 提交人 为标准来思考权限：
- 增：是否可以添加数据，可以添加数据的那些字段。
- 删：是否可以删除数据，是否可删除自己添加的数据，还是可以删除别人（任何人、某类人）添加的数据也可以删除。
- 查：是否可以查看数据，是可以查看自己添加的数据，还是可以查看别人（任何人、某类人）添加的数据；可以查看数据的哪些字段，禁止查看数据的哪些字段。
- 改：是否可以更改数据，是可以更改自己添加的数据，还是可以更改别人（任何人、某类人）添加的数据；可以更改数据的哪些字段，禁止查看数据的哪些字段。
一般情况下，权限系统的设计部分根据人员来分配，而会根据给人员分配角色，通过给不同角色赋予不同权限，来限定不同人员的权限范围。
以上是粗略的分析，针对具体的业务还要具体分析。最近做一个学校教务 CRM 系统，除了 admin，里面按照工作逻辑，角色有如下划分：
- 网站管理员：统筹网站控制，基础信息录入
- 管理者（领导）：可以查看所有统计数据
- 班主任：需要录入大量数据，查看本班级数据，公共数据
- 教师：需要录入大量数据，查看自己录入的数据，公共数据
- 其他：需要录入少量数据，查看自己录入的数据，公共数据
在数据层面主要划分为：
- 自己录入的数据
- 班级数据集合
- 公共数据集合
同时，大部分数据集，增删查改有时间限制，一般过了某个时间点数据只能查看，不能增删改，若需变动，向 管理者 申请通过 网站管理员 变动。
以此为背景，设计背后的权限逻辑，及具体的代码实现，做到代码和权限控制低耦合。
（开坑，待续……）