MyBatisPlus lambdaQuery使用演进与维护陷阱解析

1. MyBatisPlus的lambdaQuery使用演进与维护陷阱

作为一名长期使用MyBatisPlus的开发老兵，我见过太多项目从优雅简洁的查询代码逐渐演变成无人敢碰的"祖传代码"。lambdaQuery()确实是个好工具，但就像任何强大的工具一样，不当使用反而会带来更大的麻烦。今天我们就来聊聊lambdaQuery的"七年之痒"——为什么初期用着顺手的查询方式，后期会变成维护噩梦。

先看一个典型场景：新项目启动时，我们写的查询是这样的：

java复制List<User> users = userMapper.selectList(
    lambdaQuery()
        .eq(User::getStatus, 1)
        .eq(User::getDeleted, 0)
);

这种写法有三大优势：

1. 字段安全：编译时检查，重构不失效
2. IDE友好：自动补全和跳转一应俱全
3. 语义清晰：一眼就能看懂查询条件

2. lambdaQuery的渐进式恶化过程

2.1 第一阶段：简单条件查询

项目初期，查询通常只涉及2-3个固定条件。就像上面的例子，查询未删除的有效用户。此时的代码堪称完美——简洁、明确、自解释。

经验之谈：这个阶段应该建立查询条件的基本规范，比如统一使用lambdaQuery而非普通QueryWrapper，约定字段比较使用eq/ne等明确的方法名。

2.2 第二阶段：引入动态条件

随着业务发展，查询开始需要支持可选参数：

java复制List<User> users = userMapper.selectList(
    lambdaQuery()
        .eq(status != null, User::getStatus, status)
        .like(StringUtils.isNotBlank(keyword), User::getName, keyword)
        .eq(User::getDeleted, 0)
);

这种写法依然优雅，比传统的if语句拼接SQL更清晰。MyBatisPlus的条件谓词（第一个参数为boolean）让动态查询变得非常直观。

2.3 第三阶段：业务逻辑渗入查询

问题通常从业务规则开始混入查询条件时显现：

java复制List<User> users = userMapper.selectList(
    lambdaQuery()
        .eq(User::getDeleted, 0)
        .eq(User::getStatus, 1)
        .or()
        .eq(User::getLevel, 3)
);

此时的代码已经开始变得难以理解：

• or()影响的范围是什么？