MyBatis on 牛哥聊技术

几种数据权限控制方案的探索与最佳实践

Sat, 09 Jul 2022 16:30:00 +0800

数据权限是什么，为什么麻烦

很多人混淆"权限"的两个层面：

功能权限（菜单/按钮/接口能不能访问）——一般用 RBAC 解决，前端隐藏菜单 + 后端拦截器校验角色
数据权限（同一个接口看到的数据范围不同）——更隐蔽、更难做对、出问题更严重

举个最常见的例子：

销售经理 A 调 /orders 接口，应该只看到自己团队的订单；销售经理 B 调同一个接口，应该只看到自己团队的；总监能看到全部。

接口完全相同，入参完全相同，但每个人看到的数据不一样。这就是数据权限。

数据权限做错了通常造成两类问题：

越权（漏数据）：用户看到了不该看到的（合规事故、信息泄漏）
过滤（少数据）：用户该看到却看不到（业务投诉）

下面把工程里常见的几种方案过一遍，从最朴素到最优雅。

方案一：在业务方法里硬写过滤条件

最朴素的写法——在每个查询接口里手动加 where：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public List<Order> queryOrders(OrderQuery q) {
 Long currentUserId = UserContext.current().getUserId();
 String role = UserContext.current().getRole();

 if ("ADMIN".equals(role)) {
 // 看全部
 } else if ("MANAGER".equals(role)) {
 q.setTeamId(getMyTeamId(currentUserId));
 } else {
 q.setOwnerUserId(currentUserId);
 }
 return orderMapper.selectByQuery(q);
}

它的问题：

重复劳动——每个查询接口都要写一遍这套判断
极易漏写——新增接口忘了加权限，瞬间漏数据
业务和权限耦合——业务代码看不清，“业务逻辑 + 权限逻辑"混在一起
角色变更代价大——新加一种角色要改几十处接口

生产环境永远不应该这样写。 但它是所有数据权限故事的起点——理解了它的痛，才能理解后面方案的价值。

方案二：注解 + AOP 拦截

把"这个接口受数据权限控制"变成一个声明：

1
2
3
4


@DataScope(scopeType = "ORDER", deptColumn = "dept_id", userColumn = "owner_id")
public List<Order> queryOrders(OrderQuery q) {
 return orderMapper.selectByQuery(q);
}

切面在方法执行前，根据当前用户的角色和数据权限规则，把对应的过滤条件塞到查询参数里：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


@Around("@annotation(scope)")
public Object inject(ProceedingJoinPoint pjp, DataScope scope) throws Throwable {
 Object[] args = pjp.getArgs();
 for (Object arg : args) {
 if (arg instanceof BaseQuery q) {
 String filter = buildFilter(scope);
 q.setDataScopeSql(filter); // 塞条件
 }
 }
 return pjp.proceed();
}

private String buildFilter(DataScope scope) {
 User u = UserContext.current();
 if (u.hasRole("ADMIN")) return "";
 if (u.hasRole("MANAGER")) {
 return scope.deptColumn() + " IN (" + getDeptIds(u) + ")";
 }
 return scope.userColumn() + " = " + u.getUserId();
}

XML 里把条件塞进 SQL：

1
2
3
4
5
6
7
8
9


<select id="selectByQuery" parameterType="OrderQuery" resultType="Order">
 SELECT * FROM orders
 <where>
 <if test="status != null">AND status = #{status}</if>
 <if test="dataScopeSql != null and dataScopeSql != ''">
 AND ${dataScopeSql}
 </if>
 </where>
</select>

这是 若依（RuoYi）等开源后台管理系统的经典做法。

它的优劣

优点：

业务代码干净——只多一个注解
权限规则集中——所有角色判断都在切面里
接入新接口成本低

缺点：

${...} 拼接字符串——SQL 注入风险，必须严格清理输入
强依赖业务参数对象的字段——setDataScopeSql 要在每个 Query 上都有
AOP 时机偏晚——不是真正的"对所有 SQL 通用”，跨表 join、子查询场景容易漏

方案三：MyBatis 拦截器改写 SQL

更通用的姿势——直接在 SQL 执行前改写它。MyBatis 的 Interceptor 可以拦截 Executor.query，拿到原始 SQL 后用 SQL 解析器（Druid / JSqlParser）改写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


@Intercepts({
 @Signature(type = StatementHandler.class, method = "prepare", args = {Connection.class, Integer.class})
})
public class DataScopeInterceptor implements Interceptor {

 @Override
 public Object intercept(Invocation invocation) throws Throwable {
 StatementHandler sh = (StatementHandler) invocation.getTarget();
 BoundSql boundSql = sh.getBoundSql();

 String origin = boundSql.getSql();
 String rewritten = rewrite(origin);
 ReflectUtil.setField(boundSql, "sql", rewritten);
 return invocation.proceed();
 }

 private String rewrite(String sql) {
 // 用 JSqlParser 解析，识别要保护的表，加上 where
 Statement stmt = CCJSqlParserUtil.parse(sql);
 // 遍历所有 SELECT，检测到包含 orders 表时附加 dept_id IN (...)
 // ...
 return modified;
 }
}

MyBatis-Plus 的多租户、数据权限插件都是这个思路：

1
2
3
4
5
6


public class TenantSqlParser implements ISqlParser {
 @Override
 public SqlInfo processParser(Statement statement, ...) {
 // 自动给 SELECT/UPDATE/DELETE 加上 tenant_id = ?
 }
}

它的优劣

优点：

覆盖所有 SQL——不管 Mapper 怎么写，最终改写的是真正执行的 SQL
业务零侵入——不需要加注解、不需要改 Mapper
能处理 join、子查询——SQL 解析器懂语法树

缺点：

实现复杂——JSqlParser 要熟，否则改写错了就 SQL 报错
性能开销——每条 SQL 都过一遍解析器（不过相对 DB 耗时可忽略）
白名单/黑名单维护——不是所有表都受数据权限限制（系统配置表、字典表），要有规则识别

方案四：多租户场景的"自动 tenant_id"

如果你的数据权限本质就是"按租户隔离"，可以更简单——所有表都加一个 tenant_id 字段，所有 SQL 都自动带上 WHERE tenant_id = ?。

MyBatis-Plus 的实现方式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Bean
public MybatisPlusInterceptor mpInterceptor() {
 MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
 interceptor.addInnerInterceptor(new TenantLineInnerInterceptor(new TenantLineHandler() {
 @Override public Expression getTenantId() {
 return new LongValue(UserContext.current().getTenantId());
 }
 @Override public boolean ignoreTable(String tableName) {
 return Arrays.asList("sys_dict", "sys_config").contains(tableName);
 }
 }));
 return interceptor;
}

之后所有查询自动带 tenant_id，包括子查询和 join 内部。

这是 SaaS 系统数据隔离的事实标准。

方案五：基于行级安全（RLS）的数据库原生方案

Postgres / Oracle 都支持 Row-Level Security，可以让数据库根据"当前 session 的标识"自动过滤行：

1
2
3
4
5
6
7
8


-- Postgres
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
 USING (tenant_id = current_setting('app.tenant_id')::bigint);

-- 应用每次连接后设置 session 变量
SET app.tenant_id = 123;

优势：从数据库层杜绝越权，业务代码完全无感，连忘记加权限的可能都没有。

劣势：

MySQL 不原生支持（要靠 view + trigger 模拟，复杂）
需要在每次拿连接后设置 session（连接池场景要小心）
数据库故障时业务排查多一层
跨 DB 厂商兼容性差

金融、医疗等强合规场景值得用，普通业务大可不必。

设计层面：数据权限模型怎么搞

不论用哪种实现方案，数据权限的核心是『谁、对什么数据、有什么操作权』。常见模型：

1. 基于部门/组织树

1
2
3
4
5


公司
├─ 销售一部
│ ├─ A 组
│ └─ B 组
└─ 销售二部

权限范围一般有 4 种：

本人：owner_id = currentUserId
本部门：dept_id = currentDeptId
本部门及子部门：dept_id IN (currentDept + 所有子部门)
全部

实现关键是部门树要有层级关系——通常每个 dept 表里有 parent_id 加 path（如 /1/3/8/），子部门用 LIKE 查就行：

1

WHERE dept.path LIKE '/1/3/%'

2. 基于自定义数据范围

部门模型不够灵活时，加一张"用户数据范围表"：

user_id	data_scope_type	data_scope_value
100	DEPT	1,2,3
100	OWNER	self
200	ALL	-

权限灵活但配置复杂度上升。

3. 基于策略（Policy）

更进阶——每条策略描述"什么角色能看什么条件下的什么数据"：

1
2
3
4
5
6
7


policies:
 - role: SALES_MANAGER
 resource: order
 scope: "dept_id IN ${myDept + childDept}"
 - role: FINANCE
 resource: order
 scope: "amount > 0 AND status != 'DRAFT'"

这是大型系统、SaaS 平台的做法，但对中小项目过度设计。

工程上的实战建议

flowchart TD
 Start([需要做数据权限?])
 Start --> Type{什么类型?}
 Type -->|租户隔离| MT[MP TenantLine 插件
所有 SQL 自动加 tenant_id]
 Type -->|按部门看数据| Mode{规则简单 or 复杂?}
 Mode -->|简单 4 种范围| AOP[注解 + AOP + Query 字段]
 Mode -->|复杂自由组合| Interceptor[MyBatis 拦截器 + JSqlParser 改写]
 Type -->|强合规要求| RLS[数据库 RLS]

具体几条建议：

先理清模型再写代码——画清楚"角色 → 范围 → 表"的对应表
优先选侵入小的方案——MyBatis 拦截器 / MP 多租户插件好过 AOP，AOP 好过硬编码
白名单和黑名单要明确——字典表、系统配置表不应该被权限过滤；防止"管理员配置了字典却看不到"
失败要"看不到"而不是"报错"——越权应该是"你不该看到的就直接没返回"，不是抛异常告诉攻击者"你越权了"
测试用例必须覆盖——每种角色都要专门测试：A 角色看到的、不该看到的、边界数据
审计日志必须打——重要查询的"用户身份 + 看到的数据范围"要记录，事后追溯
写操作也要校验——别只做查询权限；UPDATE/DELETE 一样要校验"这条数据是不是这个用户能改的"

小结

数据权限做对的关键不在框架选型，在模型抽象和工程纪律。

把全文压一句：

数据权限是『隐式过滤』——业务代码不该感知它，但它必须无处不在。

不同规模的项目对应方案：

小项目、固定几种角色 → 注解 + AOP，把规则集中起来
多租户 SaaS → MP TenantLine 插件，零侵入自动隔离
复杂角色 × 部门 × 自定义范围 → MyBatis 拦截器 + JSqlParser 自动改写
强合规 → 数据库 RLS

不管哪一种，让"忘记加权限"在架构上不可能发生——这才是真正的数据权限设计。

MyBatis 增强工具选型：MyBatis-Plus 与通用 Mapper 全面对比

Fri, 25 Oct 2019 20:00:00 +0800

写在前面

如果你写过原生 MyBatis，一定经历过这种崩溃时刻——

1
2
3
4
5
6
7
8
9



<select id="selectByCondition" resultType="User">
 SELECT id, name, age, status FROM user
 <where>
 <if test="name != null">AND name = #{name}</if>
 <if test="age != null">AND age = #{age}</if>
 <if test="status != null">AND status = #{status}</if>
 </where>
</select>

每张表都要写一遍 CRUD，字段一变就改十几个 XML，任何"按字段查"“按字段更新"都要新加一段 SQL。**这种重复劳动催生了两个现象级开源项目 **：

通用 Mapper（tk.mybatis）：刘增辉（abel533）2014 年开源
MyBatis-Plus（MP）：苞米豆团队 2016 年开源

两者都自称"MyBatis 增强工具”，新人选型时常常分不清。本文把这两个项目从设计哲学、能力边界、典型用法、踩坑点一一对照，给出明确的选型建议。

一句话定位

通用 Mapper：在 MyBatis 上提供"通用 SQL 模板"，让你不写 XML 就能完成基础 CRUD。

MyBatis-Plus：在 MyBatis 上提供"增强能力 + 工具集"，目标是把 MyBatis 用得像 JPA 一样省事，同时保留 MyBatis 的灵活性。

通用 Mapper 是"做减法"——少写 XML；MyBatis-Plus 是"做加法"——给你一整套生态工具。

一、通用 Mapper 是怎么工作的

通用 Mapper 的核心思想：给你一个泛型 Mapper<T>，里面已经定义了一堆通用方法，框架在运行时根据泛型类型生成对应的 SQL。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


public interface UserMapper extends Mapper<User> {
}

@Service
public class UserService {
 @Autowired private UserMapper userMapper;

 public User get(Long id) { return userMapper.selectByPrimaryKey(id); }
 public int add(User u) { return userMapper.insert(u); }
 public int update(User u) { return userMapper.updateByPrimaryKey(u); }
 public int remove(Long id) { return userMapper.deleteByPrimaryKey(id); }
}

实体类用 JPA 风格注解：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Table(name = "user")
public class User {
 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;
 private String name;
 private Integer age;
 @Column(name = "status_code")
 private Integer status;
}

它的核心方法分几大类：

接口	提供能力
`BaseSelectMapper`	selectByPrimaryKey 等
`BaseInsertMapper`	insert
`BaseUpdateMapper`	updateByPrimaryKey
`BaseDeleteMapper`	deleteByPrimaryKey
`ConditionMapper`	通过 Example 条件查询
`RowBoundsMapper`	分页（基于 RowBounds）

复杂条件用 Example：

1
2
3
4
5


Example example = new Example(User.class);
example.createCriteria()
 .andEqualTo("status", 1)
 .andLike("name", "张%");
List<User> users = userMapper.selectByExample(example);

风格非常贴近 JPA Specification，有点"老 SSH 时代"的味道。

二、MyBatis-Plus 是怎么工作的

MyBatis-Plus 的核心入口是 BaseMapper<T> 和 IService<T> 两层抽象：

1
2
3
4
5
6
7
8
9


public interface UserMapper extends BaseMapper<User> {
}

public interface UserService extends IService<User> {
}

@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements UserService {
}

实体类用 MP 自家注解（也可继承 Model<T>）：

1
2
3
4
5
6
7
8
9


@TableName("user")
public class User {
 @TableId(type = IdType.AUTO)
 private Long id;
 private String name;
 private Integer age;
 @TableField("status_code")
 private Integer status;
}

最闪光的是它的 LambdaQueryWrapper——以方法引用代替字符串字段名，全程类型安全：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


List<User> users = userMapper.selectList(
 new LambdaQueryWrapper<User>()
 .eq(User::getStatus, 1)
 .like(User::getName, "张")
 .orderByDesc(User::getId)
);

userMapper.update(null,
 new LambdaUpdateWrapper<User>()
 .set(User::getStatus, 0)
 .eq(User::getId, 100L)
);

字段重命名时编译器会立刻报错，再也不用拼字符串。

三、能力对比

	通用 Mapper	MyBatis-Plus
基础 CRUD	✓	✓
条件构造	Example（字符串字段）	LambdaQueryWrapper（类型安全）
分页	RowBounds（物理分页要插件）	PaginationInterceptor（开箱即用）
主键策略	JPA `@GeneratedValue`	`IdType.AUTO/INPUT/ASSIGN_ID/ASSIGN_UUID` 等
自动填充	✗	`@TableField(fill = ...)` + Handler
逻辑删除	✗	`@TableLogic` 自动 where deleted=0
乐观锁	✗	`@Version` 自动 where version=#{old}
多租户	✗	TenantLineInnerInterceptor
数据权限/字段加密	✗	插件机制
代码生成器	第三方	官方代码生成器 + AI Friendly
ActiveRecord	✗	`Model<T>`（争议特性，不推荐用）
性能分析插件	✗	慢 SQL 输出、SQL 注入检测

简单说：通用 Mapper 只解决"少写 CRUD SQL"，MyBatis-Plus 是一整套生态。

四、设计哲学差异

通用 Mapper：贴近 JPA、最小侵入

用的是 javax.persistence.* 注解，和 JPA 互通——理论上可以无缝切到 Spring Data JPA
不引入新概念，学习成本极低
一切以"少写 SQL"为目标，不试图替你做更多事

MyBatis-Plus：全套生态、约定大于配置

自家注解 @TableId、@TableField、@TableLogic 等，绑定较深
提供了大量"开箱即用的便利"——逻辑删除、乐观锁、自动填充、分页都不用自己写代码
从 ORM 一直管到代码生成、慢 SQL 监控

简单总结：

通用 Mapper 是"工具"，MyBatis-Plus 是"框架"。

五、典型场景对比

场景 1：分页

通用 Mapper 自己只支持 RowBounds，物理分页要配合 PageHelper：

1
2
3


PageHelper.startPage(1, 10);
List<User> users = userMapper.selectAll();
PageInfo<User> page = new PageInfo<>(users);

MyBatis-Plus 自带分页插件：

1
2
3
4


IPage<User> page = userMapper.selectPage(
 new Page<>(1, 10),
 new LambdaQueryWrapper<User>().eq(User::getStatus, 1)
);

场景 2：逻辑删除

通用 Mapper 没有原生支持，要么写 SQL，要么自己注入 SqlInterceptor。

MyBatis-Plus 一个注解搞定：

1
2


@TableLogic
private Integer deleted; // 0 未删，1 已删

之后所有 selectXxx、deleteXxx 自动带上 WHERE deleted = 0，省心。

场景 3：自动填充 createTime / updateTime

通用 Mapper 要靠拦截器或自己手写。

MyBatis-Plus：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@TableField(fill = FieldFill.INSERT)
private LocalDateTime createTime;

@TableField(fill = FieldFill.INSERT_UPDATE)
private LocalDateTime updateTime;

@Component
public class MetaHandler implements MetaObjectHandler {
 @Override public void insertFill(MetaObject m) {
 this.strictInsertFill(m, "createTime", LocalDateTime.class, LocalDateTime.now());
 this.strictInsertFill(m, "updateTime", LocalDateTime.class, LocalDateTime.now());
 }
 @Override public void updateFill(MetaObject m) {
 this.strictUpdateFill(m, "updateTime", LocalDateTime.class, LocalDateTime.now());
 }
}

这种"业务无感"的能力是 MP 的杀手锏。

六、坑与争议

通用 Mapper 的坑

Example 用字符串字段名——重构改字段名时不报错，运行时才挂
生态薄——分页、性能监控、代码生成都要自己整合第三方
维护活跃度低——近几年更新明显放缓

MyBatis-Plus 的争议点

Wrapper 写多了 SQL 会变难读——复杂查询还是建议回到 XML
ActiveRecord (Model<T>) 模式虽然炫，但耦合实体和持久层，不推荐生产用
绑定较深——后期想换框架成本比通用 Mapper 高
历史上有过 SQL 注入 CVE——升级版本要及时跟

最值得提醒的一点：Wrapper 不要写超过 3 层的复杂条件。可读性是 SQL 维护的天花板。

七、选型建议

	通用 Mapper	MyBatis-Plus
单表 CRUD 占主导	✓	✓✓ （更顺手）
复杂多表 SQL	XML 写	XML + Wrapper 混用
团队熟悉 JPA	✓	△
想用全套生态工具	✗	✓
介意框架侵入	✓ 轻	△ 较重
项目活跃度需求	△	✓
学习曲线	平	略陡（Wrapper、插件多）
社区资料	较少	大量

给一个直接的建议：

新项目优先 MyBatis-Plus，社区活跃、生态完整、Lambda 类型安全，几乎没有理由选通用 Mapper。

老项目已用通用 Mapper 且稳定，没必要为了 MP 重构；对接新表时可以两者共存，MP 接 BaseMapper<T>，通用 Mapper 留旧 Mapper<T>，互不干扰。

八、共存方案

如果项目里同时存在两套 Mapper 也不冲突，但有几个细节：

包路径要分开——别让一个 Mapper 同时继承两套接口
MapperScan 要明确：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


@Configuration
public class MybatisConfig {
 @Bean
 public MapperScannerConfigurer tk() {
 MapperScannerConfigurer s = new MapperScannerConfigurer();
 s.setBasePackage("com.app.mapper.tk");
 s.setMarkerInterface(tk.mybatis.mapper.common.Mapper.class);
 return s;
 }

 @Bean
 public MapperScannerConfigurer mp() {
 MapperScannerConfigurer s = new MapperScannerConfigurer();
 s.setBasePackage("com.app.mapper.mp");
 s.setMarkerInterface(com.baomidou.mybatisplus.core.mapper.BaseMapper.class);
 return s;
 }
}

实体类注解最好不要混用——同一个实体要么用 javax.persistence.*，要么用 @TableName/@TableId，别两边都加

小结

把全文压成一句话：

通用 Mapper 是 MyBatis 的"轻量减法"，MyBatis-Plus 是 MyBatis 的"完整加法"。在 2019 年之后的新项目，几乎没有理由再选通用 Mapper。

不管选哪个，记住几个一致的工程纪律：

不要被工具骗了，别碰复杂多表 Wrapper——XML 永远是复杂查询的归宿
不要写 ActiveRecord——实体类只描述结构，不调持久层方法
不要忘了原生 MyBatis 的能力——MP/通用 Mapper 都只是 MyBatis 的扩展，复杂场景永远可以回到 Mapper.xml

把工具当工具用，别让工具反过来定义你的代码风格——这是任何框架选型都通用的原则。