1. 一个看似简单的条件判断怎么就埋了雷做后端开发的朋友尤其是长期跟Java技术栈打交道的对MyBatis这套持久层框架肯定不陌生。它那个动态SQL功能用起来是真的顺手尤其是if标签几乎每个Mapper文件里都能见到它的身影。我们平时写条件查询、写更新语句动不动就是一堆if testxxx ! null and xxx ! 往上堆写完一跑大部分场景下都没问题久而久之就形成肌肉记忆了根本不会去多想。但问题恰恰就出在这个“肌肉记忆”上。有一次我在做一个订单状态筛选的功能前端传过来一个整型的状态值0代表“待处理”1代表“处理中”2代表“已完成”。逻辑很简单用户选了哪个状态后端就按哪个状态去数据库里捞数据。我照例在Mapper里写了一个if teststatus ! null and status ! 然后拼接AND status #{status}。写完自测了一下传1和2的时候都正常数据能查出来我就以为万事大吉了。结果测试同学跑过来跟我说“选‘待处理’的时候查出来的数据不对好像把所有的订单都返回了。”我当时第一反应是前端传参有问题抓包一看status0传得好好的。再去看SQL日志发现AND status ?这个条件压根就没拼上去。那一刻我才意识到问题出在if标签的判断逻辑上——当参数值是数字0的时候status ! 这个表达式在OGNLObject-Graph Navigation Language对象图导航语言里的求值结果居然是false导致整个条件被跳过了。这个坑的隐蔽性在于它不会报错不会抛异常SQL照样能执行只是结果集完全不是你想要的。如果你的业务逻辑对数据范围比较敏感比如权限过滤、状态隔离、金额计算这种“条件丢失”可能会引发非常严重的线上问题。所以我觉得有必要把这个事情掰开揉碎了讲清楚让更多同行少走弯路。这篇文章适合所有正在使用MyBatis的开发者不管你是刚入行的新手还是写了几年CRUD的老手只要你在Mapper里写过if标签这个坑就跟你有关。2. 为什么数字0会被if标签“吃掉”2.1 OGNL表达式的隐式类型转换规则要搞清楚这个问题得先弄明白MyBatis的if标签到底是怎么判断真假的。MyBatis底层用的是OGNL来解析test属性里的表达式而OGNL在处理!比较的时候有一套自己的类型转换逻辑。当你写status ! 的时候OGNL并不会像Java那样直接抛出一个类型不匹配的编译错误它会尝试把两边的操作数转换成“可比较”的类型。具体来说OGNL在比较一个数字和一个空字符串时会尝试把空字符串转换成数字。在OGNL的转换规则里空字符串被转成数字的时候结果是0。所以status ! 实际上变成了status ! 0。当status的值本身就是0的时候这个表达式自然就是false了。而当你传1或者2的时候1 ! 0为true条件正常拼接所以问题只在参数为0的时候才会暴露出来。这个转换规则不是MyBatis自己定的而是OGNL这个表达式引擎的默认行为。很多人误以为是MyBatis的bug其实严格来说不算bug只能说是框架之间的语义差异导致的“预期外行为”。但不管怎么定义对于开发者来说结果就是你写的判断条件跟你脑子里想的不是一回事。2.2 字符串空判断和数字零判断的本质冲突再往深一层想这个问题的根源在于我们把“空值判断”和“零值判断”混在了一个表达式里。status ! null这个判断是没问题的它只关心status是不是null。但status ! 这个判断本意是想过滤掉空字符串的情况防止前端传了个空串过来导致SQL出错。对于字符串类型的参数这个写法是合理的但对于数字类型的参数这个写法就引入了歧义。数字类型的参数它的合法取值范围里本来就包含0而0在OGNL的转换规则下又跟空字符串“等价”。这就造成了一个逻辑上的死结你既想保留0这个合法值又想过滤掉空字符串但框架层面无法区分你传进来的0到底是“数字零”还是“空字符串转换后的零”。所以对于数字类型的参数! 这个判断压根就不应该出现。我后来查了一下MyBatis的官方文档和社区讨论发现这个问题其实被反复提起过很多次但依然有大量开发者在中招。原因也很简单大部分教程和示例代码在演示if标签用法的时候都是拿字符串类型的字段举例比如用户名、地址、备注之类的清一色写的都是! null and ! 。新手照着抄遇到数字类型字段的时候也不改坑就这么埋下了。2.3 不同参数类型下的行为差异对比为了让大家更直观地理解这个问题的影响范围我整理了一个对比表格列出了常见参数类型在使用! 判断时的实际表现参数类型参数值! null结果! 结果最终是否拼接条件Integernullfalsefalse否Integer0truefalse否问题所在Integer1truetrue是Stringnullfalsefalse否Stringtruefalse否Stringabctruetrue是Long0Ltruefalse否问题所在BigDecimal0truefalse否问题所在从表里可以清楚地看到所有数值类型在值为0的时候都会触发这个问题而字符串类型只有在空串的时候才会被过滤这恰好是符合预期的。所以结论很明确数值类型的参数绝对不要在if标签里加! 这个判断。注意这里说的数值类型包括Integer、Long、Double、Float、BigDecimal等所有继承自Number的类型以及基本数据类型int、long等虽然基本类型不会有null的问题但0值同样会被过滤。3. 正确的写法到底是什么样3.1 按参数类型区分判断条件既然问题的根源是类型混淆那解决方案自然就是按类型来区分写法。对于字符串类型的参数保留! null and ! 的双重判断对于数值类型的参数只保留! null即可。这个原则听起来简单但在实际项目里很多人写着写着就忘了尤其是当Mapper文件里字段特别多的时候很容易复制粘贴导致写错。我自己的做法是在写Mapper的时候先在心里给每个参数打个标签这个是字符串那个是数字另一个是日期。然后针对不同类型用不同的判断模板。为了减少出错概率我甚至整理了一套代码片段模板在IDE里设置成快捷输入这样每次写的时候直接调模板不用手敲既快又不容易错。!-- 字符串类型参数的标准写法 -- if testuserName ! null and userName ! AND user_name #{userName} /if !-- 数值类型参数的标准写法 -- if teststatus ! null AND status #{status} /if !-- 日期类型参数的标准写法 -- if teststartTime ! null AND create_time gt; #{startTime} /if3.2 使用paramName ! null的单一判断是否足够有人可能会问那对于字符串类型我只写! null行不行答案是大部分情况下行不行取决于你的前端传参规范。如果前端保证不会传空字符串过来那只写! null是没问题的。但现实情况是前端传空串的概率非常高尤其是表单提交的时候用户没填的输入框默认就是空字符串。如果你只判断null空串就会拼到SQL里导致WHERE user_name 这种条件查询结果可能为空也可能因为数据库的隐式转换产生意料之外的结果。所以对于字符串类型! null and ! 这个双重判断还是有必要的。但要注意如果你的字符串参数需要保留空字符串作为合法值比如某个字段允许存空串那就不能过滤空串这时候只写! null就行。一切取决于业务语义没有一刀切的答案。3.3 用choose和when替代复杂判断当判断逻辑比较复杂的时候比如一个参数可能影响多个条件分支用if堆叠会让代码很难读。这时候可以考虑用choose、when、otherwise这套标签它的逻辑类似于Java里的switch-case结构更清晰。choose when teststatus ! null AND status #{status} /when otherwise AND status ! -1 /otherwise /choose不过要注意choose并不会解决OGNL的类型转换问题它只是让代码结构更清晰。如果你在when的test属性里写了status ! 该踩的坑一个都不会少。所以核心原则还是那条数值类型不要跟空字符串比较。4. 实操排查怎么快速定位和修复这类问题4.1 从SQL日志入手确认条件是否拼接当你怀疑某个查询条件没生效的时候第一步永远是看SQL日志。MyBatis可以通过配置把最终执行的SQL和参数都打印出来这是最直接的排查手段。在配置文件中把日志级别调到DEBUG就能看到类似下面的输出 Preparing: SELECT * FROM orders WHERE 11 AND status ? Parameters: 0(Integer)如果你发现Preparing的SQL里压根没有AND status ?这一段那就说明if条件判断为false条件被跳过了。这时候再去检查test表达式基本就能锁定问题。我个人的习惯是在开发阶段始终开着SQL日志每次写完一个查询就手动调一遍把各种边界值都传一遍尤其是0、空串、null这三个值。这个习惯帮我提前发现过好几次类似的问题比等到测试阶段再暴露出来要省事得多。4.2 用单元测试覆盖边界值光靠手动调接口测试很容易漏掉边界情况。更靠谱的做法是写单元测试针对每个查询方法把参数的各种边界值都覆盖到。比如对于status这个参数至少要有四个测试用例传null、传0、传1、传2。每个用例都断言返回结果的数量和内容是否符合预期。Test public void testQueryByStatusZero() { OrderQuery query new OrderQuery(); query.setStatus(0); ListOrder orders orderMapper.queryOrders(query); // 断言返回的都是待处理状态的订单 assertTrue(orders.stream().allMatch(o - o.getStatus() 0)); } Test public void testQueryByStatusNull() { OrderQuery query new OrderQuery(); query.setStatus(null); ListOrder orders orderMapper.queryOrders(query); // 断言返回所有状态的订单 assertTrue(orders.size() 0); }这两个测试用例如果都能通过说明你的if判断逻辑是正确的。如果第一个用例失败返回了所有状态的订单那就说明0值被过滤了需要去改Mapper。4.3 批量检查和修复已有Mapper的实用方法如果你接手了一个老项目里面已经有大量的Mapper文件想批量排查有没有类似的隐患可以试试用文本搜索的方式。在IDE里全局搜索! 这个字符串然后把搜索结果里所有涉及数值类型参数的if标签都找出来逐个确认。更高效的方式是写一个简单的脚本用正则表达式匹配if testxxx ! null and xxx ! 这种模式然后结合Java代码里对应参数的类型定义自动标记出可疑的地方。当然这种脚本只能作为辅助最终还是需要人工确认每个参数的业务语义。我在实际项目里做过一次这样的排查一个中等规模的项目大概有三十多个Mapper文件搜出来一百多处! 的判断其中大约有二十多处是数值类型的参数全部都有隐患。修复的方式也很简单就是把and xxx ! 删掉只保留! null。改完之后跑一遍全量单元测试确认没有回归问题就搞定了。5. 更深层的思考动态SQL的边界处理原则5.1 参数校验应该前置还是后置这个坑让我开始反思一个问题参数校验到底应该放在哪一层如果我们在Controller层或者Service层就把参数的合法性校验清楚比如规定status只能是0、1、2这三个值之一那Mapper层的if判断其实可以写得更简单甚至不需要判断空串。但现实是很多项目为了图方便把校验逻辑都堆在Mapper的动态SQL里导致Mapper文件越来越复杂各种if嵌套可读性和可维护性都很差。我的建议是能在上层校验的就在上层校验Mapper层只负责最基础的null判断和SQL拼接。这样职责更清晰也更容易测试。5.2 动态SQL的可读性和可维护性平衡动态SQL的灵活性是一把双刃剑。用得好能大幅减少重复代码用得不好就是一堆难以维护的标签堆砌。我在经历过几次因为动态SQL导致的线上问题之后给自己定了几条规矩第一单个Mapper方法里的if标签不超过五个超过就考虑拆分成多个方法或者用其他方式实现。第二所有if的test表达式必须简洁明了不写复杂的逻辑运算如果需要复杂判断放到Java代码里算好再传进来。第三每个if标签上面加一行注释说明这个条件的业务含义方便后来人理解。这些规矩看起来有点教条但确实帮我减少了很多排查问题的时间。尤其是注释这一条当你在几个月后回头看自己写的Mapper时没有注释真的很难快速回忆起当时的业务逻辑。5.3 从框架源码角度理解OGNL的行为如果你对这个问题想刨根问底可以去翻一翻OGNL的源码看看它到底是怎么处理!比较的。简单来说OGNL在比较两个对象的时候会调用OgnlOps.equal方法这个方法里有一大段类型转换的逻辑。当比较的一方是String另一方是Number的时候它会尝试把String转成Number转换失败就返回false空字符串转成0然后跟另一边的数字比较。理解了这个底层逻辑你就能举一反三知道还有哪些类似的坑。比如status 0这种判断如果status是nullOGNL会怎么处理答案是会抛异常因为null不能参与数值比较。所以如果你写了if teststatus 0当status为null的时候整个SQL会报错。这也是为什么我们强调要先判断null再做其他比较。提示OGNL的官方文档里对类型转换有详细说明但很多人从来没看过。花半个小时读一遍能帮你避开不少类似的坑。6. 常见问题速查与避坑清单6.1 高频问题排查表问题现象可能原因排查方法解决方案传0时条件不生效! 导致0被过滤查看SQL日志确认条件是否拼接去掉! 只保留! null传空串时SQL报错未过滤空串导致类型转换失败查看异常堆栈和SQL日志字符串类型加! 判断传null时SQL报错未判断null直接参与比较查看异常堆栈所有参数先判断! null条件拼接顺序错乱if标签顺序与预期不符对比SQL日志和代码逻辑调整if标签顺序日期范围查询失效日期类型误加! 查看SQL日志日期类型只判断! null6.2 我踩过的其他相关坑除了数字0被过滤这个问题我在使用MyBatis动态SQL的过程中还遇到过几个类似的坑一并分享出来希望大家也能避开。第一个坑是布尔类型的参数。布尔值在OGNL里也会参与类型转换如果你写if testisDeleted ! null and isDeleted ! 当isDeleted为false的时候同样会被过滤掉。因为false在OGNL里会被转成0然后跟空串转成的0比较结果就是相等条件不成立。所以布尔类型也只能判断! null。第二个坑是枚举类型的参数。枚举在OGNL里比较的时候默认是按名字比较的如果你传的是枚举的某个具体值判断逻辑跟字符串类似。但如果枚举实现了自定义的转换器行为可能会不一样。建议枚举类型的参数在Java层就转成字符串或者数字再传进来避免在Mapper里做复杂判断。第三个坑是集合类型的参数。当你用foreach遍历集合的时候如果集合本身是nullforeach会直接报错。所以集合类型的参数一定要先判断! null而且要注意集合为空的情况空集合和null集合在业务语义上可能不同需要根据实际情况处理。6.3 给团队新人的建议如果你是一个刚入行的开发者或者团队里有新人我建议在代码审查环节就把这类问题拦住。具体做法是在Review Mapper文件的时候重点检查所有if标签的test表达式看看有没有数值类型跟空字符串比较的情况。这个检查花不了多少时间但能避免很多线上问题。另外可以把这个规则写进团队的开发规范文档里作为动态SQL编写的强制要求。规范这种东西写的时候觉得麻烦但真正执行起来能省下大量排查问题的时间。我们团队现在就是这么做的新来的同事入职第一周就会被告知这条规则效果还不错。7. 写在最后的一点个人体会这个MyBatis的if标签坑说起来原理不复杂但真正踩过的人才知道有多隐蔽。它不像空指针异常那样直接给你报错而是悄无声息地改变了你的查询逻辑让你在错误的数据基础上做决策。我后来养成了一个习惯每次写完带条件的查询都会把参数值为0、空串、null这三种情况各跑一遍确认SQL拼接符合预期再提交代码。这个习惯看起来有点笨但确实帮我省了不少返工的时间。技术这东西很多时候不是懂了多少高大上的概念而是把这些细枝末节的坑一个个填平代码的稳定性自然就上来了。希望这篇分享能帮你避开这个坑如果你也有类似的经历欢迎一起交流。
