两家客户的事故放在一起看特别扎心：一家离职员工的账号半年后还能登录，删了三条客户资料才被发现；另一家的实习生点开了工资报表，全公司数字尽收眼底。两个系统都做了登录，但后端系统开发的权限设计远不止登录这一步，谁能看、谁能改、能改到什么范围，每一层都要提前想清楚。
权限其实有三层
第一层是菜单权限：不同角色登录后看到的菜单不一样，业务员看不到财务模块。第二层是按钮权限：同一张订单页，主管有删除按钮，普通员工只有查看和编辑。第三层最容易被漏掉——数据权限：同样是业务员，张三只能看自己的客户，李四是华东区的，能看整个区的。三层都做齐，权限体系才算闭环。多数出事的系统，都只做了第一层，看着有登录，细问全是敞开的门。
通用做法是三张表
- 用户表：记录人，每人至少属于一个角色；
- 角色表：比如老板、财务、业务员、仓库，权限挂在角色上而不是直接挂在人上；
- 权限表：把每个菜单、每个按钮、每类数据操作定义成一条条权限项。
新来一个员工，给他配个角色就完事，不用逐项勾选几十条权限。这个结构俗称RBAC，听起来洋气，本质就是不让权限和人直接挂钩，中间加一层角色做缓冲，管理成本立刻降下来。
数据权限是坑最多的地方。常见错误是硬编码：代码里写死了业务员只看自己的数据，后来出现主管要看全组数据的需求，就得改代码发版本。规范做法是数据范围做成可配置的：本人、本组、本部门、全部，四档配在角色上，需求变了改配置就行。另外要防一个隐形漏洞：列表页做了过滤，详情页却没做，改一下网址里的编号照样能看别人的单子，验收时专门让两个不同权限的账号互点对方的单据试试。
立项时就该画角色表
后端系统开发的权限设计最好在需求阶段就动手：把公司里所有岗位列出来，每个岗位能做什么、不能做什么，画成一张表给开发方。这张表同时就是验收清单，上线时按岗位逐个账号过一遍，这是后端系统开发验收里最值得花时间的一环。等开发完了再想权限，往往发现数据结构不支持，返工的代价大得多。
两条建议：上系统之前先把角色和权限矩阵画出来，拿不准的岗位问一圈业务负责人；验收时专门留半天做权限测试，每个角色登一遍、越权点一遍。比格网络交付系统时权限测试是必过环节，这块多花两天，比日后出一次事故便宜太多。
