Iniciar Sesión Ahora 说出来你可能不信，很多后台产品经理一聊到权限系统，上来就喜欢先铺一堆理论框架。但真正让人头皮发麻的，往往不是框架本身，而是打开公司后台那一刻——你发现每个用户的权限都得一个一个手工配，配完之后还得祈祷千万别出错。
今年六月我入职了一家新公司，负责中台项目，接手的第一件事就是把整个后台系统翻新一遍。翻新的第一步，我们选的就是权限体系。这一块不先做扎实，后面所有功能都像盖在沙滩上，搭什么都会塌。
当时公司系统的情况，怎么说呢，也不能说完全没有权限，但那点权限约等于没有。每个页面、每个按钮，都没按角色做区分，全凭管理员手动给每个账号单独勾选。听起来好像还能凑合，实际用起来，问题就大了。
打个比方，同一个部门同一种岗位的两个人，权限明明一模一样，但管理员得分别配两遍。再比如有人转岗，从运营调到市场，他原来的权限得一个一个收回来，新的权限再一个一个开出去，整个过程全靠人工记，漏了、错了都是常态。更崩溃的是，每次上线新功能，又得把所有相关账号挨个排查一遍，该加权限的加，不该加的别动。这哪是管权限，简直就是在玩“大家来找茬”。
所以重建权限系统时，我们没有一上来就画原型，而是先把问题拆清楚。最终把整个系统拆成了四个核心模块：组织结构管理、页面菜单设置、角色权限管理和账户管理。这四个模块听起来不算复杂，但每一个都对着一个真实的痛点。
先说说组织结构管理。
这个模块本质上是把公司的人员架构在系统里数字化。很多人觉得不就是加个部门树嘛，但真做起来，细节才是魔鬼。
比如新增部门的时候，你得先选上级部门，部门层级从集团到分公司再到具体业务线，一级一级串下来。这个操作本身不难，但它决定了后面权限继承的逻辑——子部门能不能自动继承父部门的权限？哪些权限可以往下传，哪些必须单独设置？如果组织结构本身不清不楚，后面所有基于角色的权限分配都会跟着乱套。
而且，组织结构不只是个静态的部门列表，它还涉及人员的调入调出、岗位变动、临时项目组这类动态场景。比如一个员工同时在两个部门挂着职，他的权限该按哪个部门算？是按主岗来，还是两个都生效？这些在设计组织结构模块的时候就得提前想清楚，不然后面补丁摞补丁，系统越改越重。
所以你看，组织结构管理表面上是管部门，实际上是在给整个权限体系打地基。地基歪了，后面角色和权限设计得再精细也白搭。
剩下的三个模块——页面菜单设置、角色权限管理和账户管理，每个都对应着我们在实际落地中踩过的坑，后面我会接着聊。