在企业的权限管理中，通常有两类权限，一类是页面/应用的访问权限，一类是数据权限，境界没到。。

一、为什么要搞这个权限管理？

其实吧，我刚开始也不懂为啥非得搞这个，不就是想看点东西吗？但后来发现，要是没这个，乱套了。你想啊，要是让刚来的实习生随便改数据库，那公司钱不就没了？还是说让客户看到老板的工资条？这肯定不行。所以这个权限管理就像是一个保安，或者是门卫大爷，谁想进哪个门，谁想拿什么东西，都得报备。如果不搞这个，系统就变成了一个大垃圾堆，谁都能往里扔东西，谁都能随便拿走东西。所以搞权限管理是必须的，一点都不假。

其实说白了权限管理就是为了保护数据。数据现在就是钱嘛，对吧？所以这个系统设计出来就是为了让咱们放心。不然的话，今天改错一个价格，明天删掉一个订单，后天泄露了用户密码，那咱们这工作还怎么干？老板肯定要骂死咱们。所以咱们得把这个权限系统搞得严严实实的，就像那个保险箱一样。

1.1 页面权限是啥？

这个页面权限，其实就是能不能看见按钮，能不能看见菜单。就像你在公司，有的部门能看到工资表，有的部门只能看考勤表。这也就是所谓的“页面/应用的访问权限”。比如 一个普通员工，你让他进财务系统，他点那个“导出Excel”的按钮，他点不了主要原因是他没有这个权限。这就是页面权限在起作用。它控制的是“能不能看见”，而不是“能不能改”。有时候你会发现， 你明明能看见这个按钮，但你点一下它就报错，或者直接跳转回登录页，这就是页面权限没做好，或者是你根本没有这个按钮的权限。

1.2 数据权限又是个啥？

这个数据权限就比较麻烦了它比页面权限要高级一点，也难搞一点。页面权限是看能不能看见，数据权限是看能不能看见里面的具体内容。比如说你是销售经理，那你应该能看到你手底下所有销售员的业绩。但你是个普通销售员，你就只能看到你自己的业绩。你不能看到别人的，也不能看到别的部门的业绩。这就是数据权限。这玩意儿要是设计不好，就会出现“数据打架”的情况。比如 你明明没权限看，后来啊你在界面上看到了然后你点了后来啊系统给你跑了个全表查询，把不该看的数据都查出来了这就凶险了。

二、怎么设计这个系统？RBAC是个啥？

说到设计，咱们就得提一提RBAC。这个RBAC听着挺高大上的，其实就是“基于角色的访问控制”。咱们把它拆开了看，就是“角色”和“权限”的关系。

先说说得有“用户”。用户就是咱们干活的人，老王、小李、张三，都是用户。

接下来得有“角色”。角色就是给用户戴的一个帽子。比如“管理员”是一个角色，“销售经理”是一个角色， 我CPU干烧了。 “普通员工”也是一个角色。老王是管理员，小李是销售经理，张三是普通员工。

然后得有“权限”。权限就是具体能干啥。比如“删除用户”是一个权限， 破防了... “查看工资”是一个权限，“修改商品价格”也是一个权限。

再说说就是这三者的关系。用户属于角色，角色拥有权限。老王属于“管理员”角色，所以老王拥有所有权限。小李属于“销售经理”角色，小李就拥有“查看销售报表”的权限， ICU你。 但小李没有“删除系统设置”的权限。这样是不是就清楚了？把复杂的问题简单化，这就是RBAC的精髓。

2.1 数据库怎么建表？

搞清楚了RBAC，咱们就得在数据库里建表了。这个表怎么建？咱们得想想。

我CPU干烧了。 先说说肯定得有个用户表吧？就叫sys_user好了。这里面存啥？存用户名、密码、手机号、状态。密码得加密啊，不能明文存，不然被人黑了就完了。

然后是角色表sys_role。存啥？存角色名，比如“管理员”、“客服”。还有个role_key这个挺重要的， 地道。 以后代码里判断权限的时候，可能会用到这个key。

接下来是权限表sys_permission。这个表比较复杂。主要原因是权限有可能是菜单，有可能是按钮，还有可能是接口。咱们得用一个字段来区分。比如type字段，1代表菜单，2代表按钮，3代表接口。还有parent_id这个是给树形结构用的。一级菜单的parent_id是0，二级菜单的parent_id就是一级菜单的id。这样递归下去，就是一个菜单树了。

换个角度。 再说说 也是最关键的一张表，叫“角色-权限关联表”sys_role_permission。这个表就是用来连接角色和权限的。比如 行1是“管理员”角色id，列2是“删除用户”权限id，这就代表“管理员”角色拥有“删除用户”的权限。

还有一张“用户-角色关联表”sys_user_role。这个表就是用来连接用户和角色的。比如行1是“老王”的用户id，列2是“管理员”的角色id，这就代表“老王”是“管理员”。

表建好了咱们是不是还得有个部门表？主要原因是数据权限很多时候是按部门来的。比如你只能看你部门的订单。 划水。 那得有个sys_dept表，存部门名字、部门编码、父部门id。这个也挺简单的。

三、数据权限到底咋实现？

这可是个技术活，也是最容易出问题的地方。数据权限，说白了就是在SQL查询的时候，加个限制条件。

比如咱们要查用户列表。如果是超级管理员，那就把所有用户都查出来不加限制。如果不是超级管理员，那就得看他的角色，太顶了。。

如果这个角色有“本部门数据权限”，那SQL就得加上WHERE dept_id = 当前用户的dept_id。这样，他就只能查到他们部门的人，共勉。。

KTV你。 如果这个角色有“本部门及子部门数据权限”，那SQL就得复杂点了。可能得用个递归查询，或者写个临时表。反正就是要把下属部门的数据也算上。

如果这个角色有“全部数据权限”，那就不用加任何限制，查全表。

如果这个角色是“仅本人数据权限”，那SQL就得是WHERE user_id = 当前用户的id。这就很严格了，最终的最终。。

3.1 动态SQL怎么写？

在MyBatis或者JPA里咱们得用动态SQL来实现这个功能。标签、标签，这些都得用上。根据用户的不同权限，拼接不同的SQL片段。这就有点像搭积木一样。如果用户有权限A，就加一段A的代码；如果用户有权限B，就加一段B的代码。再说说拼成一条完整的SQL语句去施行。

但是这里面有个坑。就是数据权限的过滤，得在查询之前做，而不是查询之后做。如果查询之后过滤，那性能就太差了查出来一百万条数据，然后你在内存里过滤，那不是找死吗？所以必须要在数据库层面就过滤掉。这就要求咱们在写代码的时候，就得把逻辑想清楚，什么时候加条件，什么时候不加条件。

四、代码层面怎么控制？

数据库搞定了代码怎么写？现在主流的框架，像Spring Security，或者Shiro，都有现成的权限校验功能。咱们可以直接用。

4.1 注解是个好东西

在Java代码里咱们可以加注解。比如@RequiresPermissions。这就表示这个方法需要“user:add”这个权限才能施行。如果用户没有这个权限，代码就会抛异常，或者直接返回403 Forbidden。这样咱们就不用在方法里面手写一大堆if-else判断了。注解一加，系统自动帮你检查。

4.2 拦截器或者过滤器

除了注解，咱们还可以用拦截器。在请求进来的时候，拦截器先看看这个请求需要什么权限。然后看看当前登录的用户有没有这个权限。如果没有，直接拦截，不让请求往下走。拦截器的优先级比注解可能要高一点，主要原因是它是在方法施行之前就拦截了。

他破防了。 还有一种方式，就是AOP切面编程。咱们可以定义一个切面专门用来处理权限校验。把权限校验的逻辑抽离出来放在切面里。这样代码看起来更整洁，业务逻辑和权限逻辑就分开了。这就是所谓的“关注点分离”。虽然有点高深，但确实好用。

五、权限设计中的那些坑

说起来容易做起来难。在权限系统的设计过程中，咱们经常会遇到一些坑。如果不注意，后面维护起来会非常痛苦。

5.1 权限粒度太粗

一开始， 咱们可能只想到了菜单级别的权限，也就是“能不能看见菜单”。但是菜单下面还有按钮，比如“编辑”、“删除”、“导出”。如果只控制菜单，那用户看见了按钮，点一下后台接口也没做校验，那岂不是也能干坏事？所以权限粒度得细一点，得控制到按钮级别，甚至控制到具体的字段级别。比如能不能修改价格，能不能查看手机号，这些都要控制。

5.2 角色乱套了

有时候， 咱们为了省事，会把太多的权限赋予给一个角色。比如一个“客服”角色，它既得能看客户信息，又得能修改客户信息，还得能发货，还得能退款。这样一来的话，这个客服一旦账号被盗，或者员工离职了危害就太大了。所以角色的划分要合理，尽量做到“单一职责”。一个角色最好只负责一类事情。如果确实有事情需要多个角色配合，那也可以但要尽量避免一个角色拥有太多、太杂的权限。

5.3 忘记回滚了

在做权限变更的时候， 比如给用户分配角色，或者修改用户的权限。如果这个操作失败了比如数据库报错了那数据有没有回滚？用户是不是还保留了旧的权限？如果没回滚，那用户就莫名其妙地多了权限，这很凶险。所以数据库的事务管理一定要做好。要么全成功，要么全失败，绝对不能出现中间状态。

六、 一下别记错了

好了说了这么多，其实就两点。第一，权限管理很重要，是系统的保命符。第二，设计权限系统的时候，要理清楚用户、角色、权限这三者之间的关系，要用RBAC模型。数据权限要靠动态SQL来实现，代码层面要靠注解或者拦截器来实现。

虽然我讲的可能有点乱，可能也没那么专业，但道理就是这么个道理。反正，咱们做开发的，平安意识一定要强。别觉得权限管理麻烦，它可是咱们保护公司资产的重要手段。如果大家有什么不懂的，或者觉得我讲得不对的，欢迎留言讨论。反正我也听不懂你们在说什么哈哈，功力不足。。

我不敢苟同... 再说说 希望大家都能设计出完美的权限系统，代码都跑得飞快，老板都别来查数据。这日子才过得下去。

七、拓展阅读：为什么我不推荐用Excel管理权限？

有的人可能想，反正权限也不多，用个Excel表格记一下不行吗？比如谁是谁，谁有什么权限，直接在Excel里写个备注。

哈基米！ 我劝你别这么做。真的，别这么做。Excel这种东西，太不稳定了。今天你把这一行删了明天那个用户就报错了。而且，Excel是给会计用的，不是给程序员用的。程序员是用代码说话的。如果你把权限写在Excel里那你的系统就变成了一个半成品，随时可能崩盘。而且，Excel文件很容易丢失，或者被误传出去。如果权限表泄露了那你的系统就相当于裸奔了。所以还是老老实实写代码，把权限存在数据库里吧。这才是正道。

八、 关于代码复用的一点瞎扯淡

写代码的时候，咱们要多写点通用的工具类。比如写一个工具类，专门用来检查用户权限。以后不管哪个项目，哪个模块，想检查权限了直接调这个工具类就行了。不用重复写代码。这叫代码复用，能提高开发效率。虽然有时候写通用工具类很麻烦，还要考虑各种边界条件，但长远来看，是值得的。不然的话，每个项目都从头写一遍权限检查的代码，那咱们得多累啊？累死了。所以咱们得学会偷懒，学会用现有的东西，而不是什么都自己造轮子。

九、 权限管理的未来

以后技术发展了权限管理会不会更简单？比如不用咱们手动去配置权限了系统自动分析用户的操作行为，自动给他分配权限？或者是用AI来识别谁是坏人，自动限制他的访问？我觉得这个肯定会的。现在的技术发展太快了每天都能听到新东西。不过不管技术怎么变，权限管理的核心思想是不会变的，那就是“访问控制”。把不该看的东西藏起来把不该干的事情拦下来。

咱们现在做的这些，其实都是在为未来的系统打基础。基础打得好，以后系统才好 ，才好维护。不然的话，系统越做越大， 就算.... 权限管理越来越乱，再说说就像一团乱麻，剪不断理还乱。到时候，想改个权限都得把系统搞崩溃。那可就真的尴尬了。

十、 再啰嗦几句

权限管理是个大工程。不是写几个注解就能搞定的。它涉及到数据库设计、业务逻辑、代码实现、测试验证等方方面面。咱们不能只看表面觉得“哦，我有这个功能就行了”。细节决定成败。有时候，一个参数传错了一个SQL语句少了个引号，都可能导致权限泄露。所以咱们得小心，再小心。写完代码，自己多测几遍，把各种极端情况都想一下。比如用户没有角色怎么办？角色被删除了怎么办？权限被修改了怎么办？把这些情况都想到了你的系统才算是比较健壮的。

好了我就不说了说了这么多，嗓子都干了。希望这篇文章能帮到那些正在为权限管理发愁的朋友。如果觉得还行，就点个赞吧。反正我也没指望能拿多少稿费，就是想把自己的经验分享出来。毕竟独乐乐不如众乐乐嘛。虽然我的表达可能不太清晰，逻辑可能不太严密，但我的初衷是好的。希望大家能理解。

---