1. 问题背景与现象还原

最近在项目中使用MyBatis Plus的QueryWrapper构建动态SQL时，遇到了一个典型的拼接问题。具体场景是在自定义XML映射文件中使用@Param(Constants.WRAPPER)注解配合${ew.customSqlSegment}时，生成的SQL语句出现了AND条件衔接错误。这个问题看似简单，但排查过程却让我对MyBatis Plus的条件构造器有了更深的理解。

先还原下问题现场：我需要根据前端传入的不同查询参数动态生成WHERE条件，于是写了如下Mapper接口方法：

List<User> selectUserList(@Param(Constants.WRAPPER) QueryWrapper<User> wrapper);

对应的XML映射文件是这样写的：

<select id="selectUserList" resultType="User"> SELECT * FROM user WHERE status = 1 ${ew.customSqlSegment} </select>

当wrapper中添加了多个条件时，比如：

wrapper.eq("dept_id", 10) .like("user_name", "张");

预期生成的SQL应该是：

SELECT * FROM user WHERE status = 1 AND dept_id = 10 AND user_name LIKE '%张%'

但实际执行时却变成了：

SELECT * FROM user WHERE status = 1 dept_id = 10 AND user_name LIKE '%张%'

可以看到第一个条件dept_id = 10前面缺少了AND连接词，导致SQL语法错误。

2. 问题根源分析

2.1 MyBatis Plus的条件拼接机制

要理解这个问题，需要先了解MyBatis Plus的条件构造器工作原理。QueryWrapper在生成SQL片段时，会根据是否是第一个条件自动决定是否添加AND前缀。具体逻辑在AbstractWrapper类的getNormal()方法中：

protected String getNormal() { return (StringUtils.isNotBlank(expression) ? (firstOfWhere ? "" : " AND ") + expression : ""); }

这里的firstOfWhere标记非常重要，它表示当前条件是否是WHERE子句中的第一个条件。如果是，则不添加AND前缀；否则会自动添加。

2.2 ${ew.customSqlSegment}的工作机制

当我们使用${ew.customSqlSegment}时，MyBatis Plus会将QueryWrapper中所有非空条件拼接成一个完整的SQL片段。关键点在于：

1. 这个片段会保留QueryWrapper内部的条件顺序和AND前缀
2. 但不会考虑这个片段将如何被外部SQL使用

2.3 问题产生的根本原因

在我们的例子中，XML里已经有一个固定条件status = 1，后面直接拼接${ew.customSqlSegment}。QueryWrapper不知道前面已经有WHERE条件，所以它生成的第一个条件dept_id = 10没有添加AND前缀，导致语法错误。

3. 解决方案对比

3.1 方案一：手动添加AND前缀（不推荐）

最直观的修改方式是在XML中手动添加AND：

<select id="selectUserList" resultType="User"> SELECT * FROM user WHERE status = 1 AND ${ew.customSqlSegment} </select>

这样虽然能解决问题，但存在明显缺陷：

• 如果wrapper没有添加任何条件，会生成WHERE status = 1 AND这样的非法SQL
• 破坏了QueryWrapper的自包含性

3.2 方案二：使用条件构造器包含固定条件（推荐）

更好的做法是将固定条件也放入QueryWrapper中：

wrapper.eq("status", 1) .eq("dept_id", 10) .like("user_name", "张");

然后修改XML为：

<select id="selectUserList" resultType="User"> SELECT * FROM user ${ew.customSqlSegment} </select>

这种方式的优点：

• 保持SQL生成的统一性
• 避免手动拼接带来的风险
• 所有条件都在Java代码中集中管理

3.3 方案三：使用@Select注解（动态SQL）

如果项目允许，还可以考虑完全使用注解方式：

@Select("<script>" + "SELECT * FROM user " + "WHERE status = 1 " + "<if test='ew != null'>${ew.customSqlSegment}</if>" + "</script>") List<User> selectUserList(@Param(Constants.WRAPPER) QueryWrapper<User> wrapper);

这种方式更灵活，可以添加更多动态逻辑。

4. 深入原理与最佳实践

4.1 QueryWrapper的内部状态管理

QueryWrapper内部维护了几个关键状态：

• firstOfWhere：标记是否是WHERE后的第一个条件
• paramNameValuePairs：存储参数键值对
• expression：当前条件表达式

当调用getCustomSqlSegment()时，它会遍历所有条件，根据firstOfWhere状态决定是否添加AND前缀。

4.2 条件拼接的边界情况处理

在实际项目中，还需要考虑以下边界情况：

1. wrapper为空时：应该跳过${ew.customSqlSegment}拼接
2. 混合使用固定条件和动态条件时：需要统一管理条件顺序
3. 多表关联查询时：注意表别名的一致性

4.3 性能考量

虽然${ew.customSqlSegment}很方便，但要注意：

• 大量使用字符串拼接可能影响SQL解析性能
• 复杂的动态条件建议使用<script>标签
• 对于固定模式查询，考虑使用预编译SQL

5. 常见问题排查指南

5.1 问题现象：SQL语法错误

可能原因：

• 缺少AND连接词（如本文案例）
• 条件值为空导致生成非法SQL
• 表别名不一致

排查步骤：

1. 打印实际执行的SQL（设置mybatis-plus.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl）
2. 检查WHERE子句的连接词
3. 验证条件值是否为空

5.2 问题现象：条件不生效

可能原因：

• wrapper条件被意外清空
• 参数名称不匹配（未使用@Param(Constants.WRAPPER)）
• XML中未正确使用${ew.customSqlSegment}

排查步骤：

1. 调试检查wrapper对象内容
2. 确认Mapper方法参数注解
3. 检查XML片段是否正确

5.3 问题现象：SQL注入风险

可能原因：

• 直接拼接用户输入到wrapper条件中
• 使用${}而非#{}处理参数

解决方案：

1. 始终使用wrapper的eq、like等方法处理用户输入
2. 避免直接拼接字符串到条件中
3. 对复杂查询使用XML动态SQL

6. 高级技巧与实战经验

6.1 链式调用的优雅写法

在实际项目中，可以这样组织条件构造：

public List<User> queryUsers(UserQuery query) { return userMapper.selectList(new QueryWrapper<User>() .eq(query.getDeptId() != null, "dept_id", query.getDeptId()) .like(StringUtils.isNotBlank(query.getUserName()), "user_name", query.getUserName()) .between(query.getStartTime() != null && query.getEndTime() != null, "create_time", query.getStartTime(), query.getEndTime()) .orderByDesc("create_time")); }

这种写法：

• 使用条件方法的重载版本避免空判断
• 保持代码的整洁性和可读性
• 易于扩展新的查询条件

6.2 复杂查询的构建策略

对于多表关联等复杂查询，建议：

1. 使用@SelectProvider动态生成SQL
2. 或者创建专门的Query对象和Builder
3. 对于报表类查询，考虑使用原生SQL+ResultMap

6.3 性能优化建议

1. 为常用查询条件添加数据库索引
2. 避免在wrapper中使用SELECT *
3. 对于大数据量查询，考虑分页或延迟加载

7. 替代方案比较

除了QueryWrapper，MyBatis Plus还提供了其他条件构造方式：

7.1 LambdaQueryWrapper

使用示例：

new LambdaQueryWrapper<User>() .eq(User::getStatus, 1) .like(User::getUserName, "张")

优点：

• 类型安全
• 编译时检查
• 更好的IDE支持

缺点：

• 稍复杂的表达式支持有限

7.2 QueryChainWrapper

使用示例：

userService.query() .eq("status", 1) .list();

优点：

• 更简洁的链式调用
• 与Service层更好集成

7.3 原生MyBatis动态SQL

对于特别复杂的查询，有时回退到原生MyBatis动态SQL可能是更好的选择：

<select id="selectUsers" resultType="User"> SELECT * FROM user <where> <if test="status != null"> AND status = #{status} </if> <if test="userName != null"> AND user_name LIKE CONCAT('%', #{userName}, '%') </if> </where> </select>

8. 实际项目中的经验总结

经过多个项目的实践，我总结了以下经验：

1. 保持一致性：整个项目应该统一使用一种条件构造方式，避免混用造成维护困难

2. 防御性编程：对前端传入的查询参数进行校验，避免生成危险的SQL

3. 日志记录：在生产环境记录关键查询的SQL和参数，便于问题排查

4. 性能监控：对复杂查询进行性能监控，及时发现潜在问题

5. 文档注释：为复杂的查询条件添加详细注释，说明业务含义和使用场景

这个问题的解决过程让我深刻理解到，即使是看似简单的工具，深入理解其工作原理也能避免很多陷阱。MyBatis Plus的条件构造器虽然强大，但也需要正确使用才能发挥最大价值。