MyBatis拦截器实现数据权限控制的技术方案

1. 项目背景与核心价值数据权限控制是企业级应用开发中的高频需求但传统实现方案往往面临两大痛点一是需要在每个查询方法中硬编码权限逻辑导致业务代码臃肿二是权限规则变更时需要全局修改维护成本极高。这个方案通过MyBatis拦截器实现SQL自动改写真正做到了权限控制与业务逻辑解耦。我在金融行业多个项目中验证过这种方案相比传统的AOP或Service层过滤拦截SQL的执行阶段有三大优势第一是性能损耗最小仅增加一次SQL解析第二是天然支持多表关联查询第三是兼容所有ORM操作方式包括注解、XML和MyBatis-Plus。2. 技术方案设计2.1 整体架构设计核心架构分为三个层次权限规则引擎存储当前用户的部门、角色等权限标识SQL拦截器基于MyBatis的Interceptor接口实现SQL改写器使用JSqlParser解析和修改AST// 典型拦截器配置示例 Intercepts({ Signature(type StatementHandler.class, methodprepare, args{Connection.class, Integer.class}) }) public class DataPermissionInterceptor implements Interceptor { // 核心处理逻辑 }2.2 关键实现细节2.2.1 SQL解析优化使用JSqlParser时要注意对UNION等复杂语句需要特殊处理子查询中的表别名需要递归处理内存表如WITH临时表需要跳过权限控制// 表访问控制逻辑示例 if (table.getName().equals(sys_user)) { PlainSelect select (PlainSelect)selectBody; if (select.getWhere() null) { select.setWhere(buildDataPermissionExpr()); } else { select.setWhere(new AndExpression( select.getWhere(), buildDataPermissionExpr() )); } }2.2.2 性能优化点使用ThreadLocal缓存解析后的SQL模板对COUNT查询进行特殊处理避免影响分页通过InterceptorOrder控制多个拦截器的执行顺序3. 完整实现步骤3.1 基础环境搭建添加JSqlParser依赖dependency groupIdcom.github.jsqlparser/groupId artifactIdjsqlparser/artifactId version4.6/version /dependency实现权限上下文Holderpublic class DataPermissionContext { private static final ThreadLocalSetString DEPT_SCOPE new ThreadLocal(); public static void setDeptScope(SetString deptIds) { DEPT_SCOPE.set(deptIds); } // 获取当前用户有权限的部门ID集合 public static SetString getDeptScope() { return Optional.ofNullable(DEPT_SCOPE.get()) .orElse(Collections.emptySet()); } }3.2 拦截器核心逻辑Override public Object intercept(Invocation invocation) throws Throwable { StatementHandler handler (StatementHandler)invocation.getTarget(); BoundSql boundSql handler.getBoundSql(); // 1. 跳过非SELECT语句 if (!isSelectStatement(boundSql.getSql())) { return invocation.proceed(); } // 2. 解析原始SQL Statement stmt CCJSqlParserUtil.parse(boundSql.getSql()); // 3. 改写SQL if (stmt instanceof Select) { Select select (Select)stmt; SelectBody selectBody select.getSelectBody(); modifySelectBody(selectBody); } // 4. 重置BoundSQL resetBoundSql(handler, boundSql, stmt.toString()); return invocation.proceed(); }3.3 权限规则配置支持多种配置方式注解方式DataPermission(tablesys_user, columndept_id)配置文件>// 在SQL改写阶段增加租户判断 if (isMultiTenantTable(tableName)) { Expression tenantFilter new EqualsTo( new Column(tableAlias .tenant_id), new StringValue(TenantContext.getCurrentTenant()) ); where where null ? tenantFilter : new AndExpression(where, tenantFilter); }4.2 动态表名处理对于分表场景可以通过拦截器修改物理表名if (table.getName().startsWith(order_)) { String actualTable order_ YearMonth.now().getYear(); table.setName(actualTable); }5. 生产环境注意事项SQL兼容性测试所有GROUP BY、HAVING子句场景验证UNION ALL等集合操作检查存储过程调用是否受影响性能监控// 添加监控埋点 long start System.nanoTime(); try { return invocation.proceed(); } finally { metrics.record(sql_rewrite, System.nanoTime() - start); }异常处理捕获JSqlParserException并降级为原始SQL对UPDATE/DELETE语句添加保护性检查6. 常见问题排查6.1 拦截器不生效检查项是否被其他拦截器覆盖调整Order值MyBatis配置文件中是否注册是否被Spring的事务拦截器提前处理6.2 SQL语法错误典型场景使用了保留关键字作为列名子查询别名冲突分页插件兼容性问题解决方案// 安全改写模式 try { return doRewrite(sql); } catch (Exception e) { log.warn(SQL rewrite failed, fallback to original: {}, e.getMessage()); return sql; }6.3 权限泄露风险必须验证所有管理接口是否跳过拦截器Native SQLSelectProvider是否被覆盖MyBatis-Plus的自动填充字段是否受影响7. 方案对比与选型方案类型实现复杂度性能影响维护成本适用场景Service层过滤低高高简单查询场景AOP切面中中中需要方法级控制的场景SQL拦截器高低低复杂查询和多表关联场景数据库视图低最低高权限规则极少变更的场景在实际项目中我通常会采用组合方案90%的场景用SQL拦截器实现对特别复杂的查询使用Service层补充控制。这种混合模式在保证性能的同时也兼顾了灵活性。