随便记-想到什么写什么

mybatis-plus <if>标签中如果需要进行等量判断的格式

<if test="A == 1">sql</if>
<if test="A != 1">sql</if>

//要么是==双等号  要么是!=非等号  可别这么写哈 不生效的
<if test="A = 1">sql</if>

mybatis-plus 通过.and().or()实现where ... and(... or ...)查询

//第一版的写法
LambdaQueryWrapper<Entity> wrapper = new LambdaQueryWrapper();
wrapper.eq(Entity::getAa, Aa);
if(StringUtils.isNotBlank(Bb)) {
    wrapper.eq(Entity::getBb, Bb).or().eq(Entity::getCc, Cc);
}
wrapper.eq(Entity::getDd, Dd);
List<Entity> list = XxxMapper.selectList(wrapper);

//第二版的写法
LambdaQueryWrapper<Entity> wrapper = new LambdaQueryWrapper();
wrapper.eq(Entity::getAa, Aa);
wrapper.and(i -> 
    i.or().like(StringUtils.isNotBlank(Bb), Entity::getBb, Bb)
     .or().like(StringUtils.isNotBlank(Bb), Entity::getCc, Cc)
);
wrapper.eq(Entity::getDd, Dd);
List<Entity> list = XxxMapper.selectList(wrapper);

//第三版的写法
LambdaQueryWrapper<Entity> wrapper = new LambdaQueryWrapper();
wrapper.eq(Entity::getAa, Aa);
wrapper.and(StringUtils.isNotBlank(Bb), i -> 
    i.or().like(Entity::getBb, Bb)
     .or().like(Entity::getCc, Cc)
);
wrapper.eq(Entity::getDd, Dd);
List<Entity> list = XxxMapper.selectList(wrapper);

直接说结论：用第三版的写法

第一种写法的问题：

SELECT column1,column2,column3... FROM TABLE WHERE del_flag=0 AND (Aa = Aa AND Bb = Bb OR Cc = Cc AND Dd = Dd)

mybatis-plus的where条件拼接是一种很直白的拼接方式，它并不是像编写SQL语句的时候的逻辑来实现的（Here is a big 土亢） 

第二种写法的问题：

SELECT column1,column2,column3... FROM TABLE WHERE del_flag=0 AND (Aa = Aa AND (Bb LIKE Bb OR Bb LIKE Cc) AND Dd = Dd)

是不是看起来实现了想要的结果？先别着急，这个位置有一个坑在等着你，当你的Bb判空生效时，最终的SQL结果会变成这个鬼样子

SELECT column1,column2,column3... FROM TABLE WHERE  del_flag=0  AND (Aa = Aa AND  AND Dd = Dd)

报错咯

报错原因是因为Bb的判空生效，导致中间的where条件没有生成，但是and连接条件还带着，所有SQL语句报错了

再次优化一下代码结构（也就是第三版），解决这个问题，就可以拿到正确的结果啦 

@Slf4j打印异常报错信息

直接说结论：这样写

try{
    //JSON转换代码
} catch(Exception e) {
    log.error("报错信息：", e);
}

数据库表字段中存的是JSON格式的信息，后端接口将信息取出来后在Service层转成Object然后进行相关的业务逻辑操作；

但是问题来了，因为JSON格式是前端调用第三方平台的数据获取的，整稀碎，所以在转换过程中经常出现Exception；那么就try-catch一下吧，诶，坑来了

先贴一下完整的报错信息：

然后呢，想当然的进行了对异常的打印：

try{
    //JSON转换代码
} catch(Exception e) {
    log.error("报错信息：{}", e);
}

结果就是log.error代码行出现了IDEA的黄牌警告（Fewer arguments provided (0) than placeholders specified (1)），代码运行结果：

黄牌警告的意思是在日志消息中使用了一个占位符{}但是没有正确的提供对应的参数。Lombok的@Slf4j依赖于SLF4J(Simple Logging Facade for Java)作为日志框架，SLF4J支持{}占位符并可以自动处理参数的格式化。但是实际上在代码中提供的是一个Exception对象作为参数，无法实现对该参数的格式化，所以从打印结果中可以看出来打印了一个空白的{}，后面跟着异常的打印。

既然如此就提供了两个填坑思路：

1.提供可以支持格式化的参数，也就是说{}中间传String;

2.既然在后面有打印异常的信息，那么完全可以舍弃{}，直接进行打印；

验证1：

try{
    //JSON转换代码
} catch(Exception e) {
    log.error("测试异常日志打印情况|||e.getMessage={}", e.getMessage());
    log.error("测试异常日志打印情况|||e.toString={}", e.toString());
}

结果：

可以发现不论是getMessage()方法还是toString()方法打印的信息都非常的有限，如果只是报错信息的简单展示还是挺适用的，但是我需要的是能够明确打印出保存代码行的信息，所以这个思路行不通

验证2：

try{
    //JSON转换代码
} catch(Exception e) {
    log.error("测试异常日志打印情况", e);
}

结果：

 成功得到了想要的结果，土亢填上了