共计 1145 个字符，预计需要花费 3 分钟才能阅读完成。
前言
明天和前端同学联调一个搜寻接口，该接口会在图片上传后用于加载图片列表。诡异的是，这位同学在和我联调的过程中，每次上传图片后，却始终无奈看到最新上传的图片。然而该接口在另外一个场景下是失常的，这也是我提供这个接口给他的起因。
排查过程
传了图片没被搜到？是不是上传后生成的图片 ID 没有落 DB？
看了一眼日志，果然没有 DB 相干的日志。那么是不是哪儿有做了管制，对应看了下代码，果然有个入参，跳过了图片 ID 的落库。
前端同学之前抄其他人的代码，就传了 true，所以导致图片 ID 压根败落 DB。听我一说，他立马试了下。我看日志的确走到了 DB，看来是向前了一步了呢。
不过前端同学依然反馈说，还是查不到最新的图片。我用他产生的图片 ID，去搜相干日志，确实是没有搜寻的返回。
看了半天日志，也瞥了几眼代码，还是毫无脉络。为什么明明另外一个场景可用，这个前端同学就拿不到正确后果呢？
还是做点尝试看能不能有点成果吧，我想到了两个场景做下比对。既然是同一个接口，我就在以后场景上传下图片，而后看下之前可用的那个场景是否拿到了最新图片的信息。后果是必定的。那就阐明，这两种场景的查问必定是有区别的。
和前端同学对了下两种场景的入参，发现有个搜寻关键词的字段 keyword。以前的场景时传了空字符串，而他这个场景压根没传。
我过后也没反馈过去是这个问题，就和他说，要不试试参数搞一样？
前端同学试了下，果然通了。搞了一早晨，联调终于通了，心田很是酸爽，尽管曾经早晨十一点了。
问题定位
晓得是 keyword 这个字段捣的鬼，也促使我敏感地意识到问题所在。
我想起 SQL 查问塞值的时候，keyword 作为入参被非凡解决了，如下：
param.put("keyword", "%"+keyword+"%")对应的 SQL 如下：
... where name like #{keyword} 豁然开朗，前端同学没传 keyword 时，零碎默认取到了 null，而后到 SQL 塞值的时候，天然就拼接成了 where name like '%null%'，也就是搜寻接口会去匹配图片名含 null 这个字符串的数据。
我抽取了前端同学用这个接口能查到的数据，无一例外图片名字里都有 null 这个字符串。
而传空字符串，就不会扭转语义，能匹配到所有数据。
启发
- 置信问题总能解决，在解决问题的刹那，你会有一种释然和成就感。
- 问题拆解，大问题拆解小问题，找到问题点，发现突破点，由少到多，缓缓毁灭最终问题。
- 多方面多角度剖析问题，多猜测多佐证打消问题。
- 做一些有意义的尝试，通过反馈，进一步确认本人的判断。
- 长于单干，相互疏导，相互启发，独特解决问题，达到 1 + 1 > 2 的成果。
关注我的微信公众号，回复“礼包”支付我的学习材料
涵盖自学编程、Java 技术、分布式笔记、算法刷题和程序员必读电子书等泛滥材料合集。