一般企业上的权限部分，都是区分为功能权限和数据权限。

一、功能权限

功能权限，就是用户登录后，能看到哪些菜单，能看到哪些按钮，能执行哪些操作的权限。
一般，功能权限，已经都有很成熟的业内方案和框架了。
比如有RBAC思想（Role-Based Access Control，基于角色的访问控制）。
有三个概念：用户，角色，资源。
用户就是用户，给用户配置角色，给角色配置资源，这些菜单的访问权限就是资源。
这样一来，五张表就够了。用户表，角色表，资源表，用户角色关系表，角色资源关系表。
一般业内方案有这几种：

1、基于shiro框架

这个框架把登录，验证，功能权限都做了，是一个经典的，成熟的，轻量级的框架。适合与spring集成，但不仅仅限于spring框架。
shiro初衷只是为单体应用提供方便，但随着热度增加，现在不管是单体应用还是分布式集群，都可以，网上有大段大段的介绍，我这就不说这个了，可以自行去找。

2、基于spring-security框架

这个顾名思义，spring全家桶的成员，与spring是无缝对接，但量级偏重，学习成本比shiro要大，而且常用功能方面相比shiro也没有过多优势，所以现在应该很少有用这个的，能用这个的都用shiro了。

3、其他方案

可以看下我之前写的一个方案，基于aop和注解做的，适合新手练习，只提供一个思路。
一个简单的权限系统模型

二、数据权限

数据权限就是控制用户能看到哪些数据，不能看到哪些数据。比如部门负责人，默认只能看见自己本部门下的数据，隔壁部门的一些数据一般是看不了的。
数据权限由于和业务紧密关联，所以业内一直也没有一个统一的框架或者方案，一般都是硬编码，我仅仅也是根据我遇到过的场景，提出一种稍微能规范化的思路，纯个人想法，仅供参考。

那就是使用设计模式中的模板模式，通过使用一个抽象类去定义好骨架，然后针对不同业务子类，将自己的实现补上就行。
一般骨架的步骤如下，就拿用户只能看自己部门相关数据的这个权限举例：
前提：一般业务数据，不会在数据上直接标注属于哪个部门，因为部门架构一直会变，甚至会大变，所以一般都是在业务数据上挂的是责任人。
而且，一般数据权限还要满足可配置，就好比得有一个配置，能指定让A部门的人，也能看到B部门的数据，这种算特殊情况，我们得有个表去维护记录。
1、拿到用户的这个部门
2、拿到这个部门下的所有员工集合{a,b}
3、拿到特殊情况下，对应的所有员工集合{c,d,e}
4、将上两个集合合并，作为默认情况下的员工集合A{a,b,c,d,e}
5、拿到本业务数据中所有的责任人集合B{a,b,c,x,y,z}，并与上面集合A合并，找出B集合中包含A集合的数据集合，我们叫最终集合C{a,b,c}
6、最后用员工集合C作为条件查出对应的业务数据。
以上第一步到第五步，都可以作为接口对子类下发，延迟实现，最终执行是第六步。
这样就彻底规范了所有业务的数据权限的使用步骤，各个业务只管实现即可。以上步骤可以微调，看清道理即可。

模板模式，可以参考我之前写过的一篇介绍
[设计模式] ------ 模板模式

注：使用模板模式实现数据权限，个人感觉还不是最优解，之所以使用模板，重在规范各个业务的逻辑规则顺序。

三、总结

做权限，首先要分清功能权限和数据权限的界限，最好不要有交集，不要为了编码方便，将二者揉起来，比如在数据权限的时候，很容易会想到要用功能权限里面的角色的部分，乍一看好像方便了不少，但对于日后维护，以及后面新员工的学习成本，都是很大的，因为一旦揉起来，相当于就把功能权限和数据权限耦合了，我们知道，解耦是项目做大后特别麻烦的一件事，所以能在项目初期避免耦合的，就尽量避免。所以如果项目是团队多人协同开发，大可将功能权限和数据权限交给两个人同时做。各做各的，避免耦合。