前端的菜单和按钮权限都可以通过配置来实现，但很多时候，后台查询数据库数据的权限需要通过手动添加SQL来实现。
比如员工打卡记录表，有id,name,dpt_id,company_id等字段，后两个表示部门ID和分公司ID。
查看员工打卡记录SQL为：select id,name,dpt_id,company_id from t_record
当一个总部账号可以查看全部数据此时,sql无需改变。因为他可以看到全部数据。
当一个部门管理员权限员工查看全部数据时，sql需要在末属添加 where dpt_id = #{dpt_id}
如果每个功能模块都需要手动写代码去拿到当前登陆用户的所属部门，然后手动添加where条件，就显得非常的繁琐。
因此，可以通过mybatis的拦截器拿到查询sql语句，再自动改写sql。
mybatis 拦截器
MyBatis 允许你在映射语句执行过程中的某一点进行拦截调用。默认情况下，MyBatis 允许使用插件来拦截的方法调用包括：
- Executor (update, query, flushStatements, commit, rollback, getTransaction, close, isClosed)
- ParameterHandler (getParameterObject, setParameters)
- ResultSetHandler (handleResultSets, handleOutputParameters)
- StatementHandler (prepare, parameterize, batch, update, query)
这些类中方法的细节可以通过查看每个方法的签名来发现，或者直接查看 MyBatis 发行包中的源代码。 如果你想做的不仅仅是监控方法的调用，那么你最好相当了解要重写的方法的行为。 因为在试图修改或重写已有方法的行为时，很可能会破坏 MyBatis 的核心模块。 这些都是更底层的类和方法，所以使用插件的时候要特别当心。
通过 MyBatis 提供的强大机制，使用插件是非常简单的，只需实现 Interceptor 接口，并指定想要拦截的方法签名即可。
分页插件pagehelper就是一个典型的通过拦截器去改写SQL的。
可以看到它通过注解 @Intercepts 和签名 @Signature 来实现，拦截Executor执行器，拦截所有的query查询类方法。
我们可以据此也实现自己的拦截器。
顺便加了个注解 @SqlLimit，在mapper方法上加了此注解才进行数据权限过滤。
同时注解有两个属性，
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface SqlLimit {
/**
* sql表别名
* @return
*/
String alis() default "";
/**
* 通过此列名进行限制
* @return
*/
String columnName() default "";
}
columnName表示通过此列名进行限制，一般来说一个系统，各表当中的此列是统一的，可以忽略。
alis用于标注sql表别名，如 针对sql select * from tablea as a left join tableb as b on a.id = b.id 进行改写，如果不知道表别名，会直接在后面拼接 where dpt_id = #{dptId},
那此SQL就会错误的，通过别名 @SqlLimit(alis = "a") 就可以知道需要拼接的是 where a.dpt_id = #{dptId}
执行结果
原SQL：select * from person， 数据权限替换后的SQL：select * from person where dpt_id = 234原SQL：select * from person where id > 1， 数据权限替换后的SQL：select * from person where dpt_id = 234 and id > 1
但是在使用PageHelper进行分页的时候还是有问题。
可以看到先执行了_COUNT方法也就是PageHelper，再执行了自定义的拦截器。
在我们的业务方法中注入SqlSessionFactory
@Autowired
@Lazy
private List<SqlSessionFactory> sqlSessionFactoryList;
PageInterceptor为1，自定义拦截器为0，跟order相反，PageInterceptor优先级更高，所以越先执行。
mybatis拦截器优先级
@Order
通过@Order控制PageInterceptor和MySqlInterceptor可行吗？
将MySqlInterceptor的加载优先级调到最高，但测试证明依然不行。
定义3个类
@Component
@Order(2)
public class OrderTest1 {
@PostConstruct
public void init(){
System.out.println(" 00000 init");
}
}
@Component
@Order(1)
public class OrderTest2 {
@PostConstruct
public void init(){
System.out.println(" 00001 init");
}
}
@Component
@Order(0)
public class OrderTest3 {
@PostConstruct
public void init(){
System.out.println(" 00002 init");
}
}
OrderTest1，OrderTest2，OrderTest3的优先级从低到高。
顺序预期的执行顺序应该是相反的：
00002 init
00001 init
00000 init
但事实上执行的顺序是
00000 init
00001 init
00002 init
@Order 不控制实例化顺序，只控制执行顺序。
@Order 只跟特定一些注解生效 如：@Compent @Service @Aspect … 不生效的如： @WebFilter
所以这里达不到预期效果。
@Priority 类似，同样不行。
@DependsOn
使用此注解将当前类将在依赖类实例化之后再执行实例化。
在MySqlInterceptor上标记@DependsOn("queryInterceptor")
启动报错，
这个时候queryInterceptor还没有实例化对象。
@PostConstruct
@PostConstruct修饰的方法会在服务器加载Servlet的时候运行，并且只会被服务器执行一次。
在同一个类里，执行顺序为顺序如下:Constructor > @Autowired > @PostConstruct。
但它也不能保证不同类的执行顺序。
PageHelper的springboot start也是通过这个来初始化拦截器的。
ApplicationRunner
在当前springboot容器加载完成后执行，那么这个时候pagehelper的拦截器已经加入，在这个时候加入自定义拦截器，就能达到我们想要的效果。
仿照PageHelper来写
@Component
public class InterceptRunner implements ApplicationRunner {
@Autowired
private List<SqlSessionFactory> sqlSessionFactoryList;
@Override
public void run(ApplicationArguments args) throws Exception {
MySqlInterceptor mybatisInterceptor = new MySqlInterceptor();
for (SqlSessionFactory sqlSessionFactory : sqlSessionFactoryList) {
org.apache.ibatis.session.Configuration configuration = sqlSessionFactory.getConfiguration();
configuration.addInterceptor(mybatisInterceptor);
}
}
}
再执行，可以看到自定义拦截器在拦截器链当中下标变为了1（优先级与order刚好相反）
后台打印结果，达到了预期效果。