联调踩的坑：空和空字符串引发的巨大差异

前言

今天和前端同学联调一个搜索接口，该接口会在图片上传后用于加载图片列表。诡异的是，这位同学在和我联调的过程中，每次上传图片后，却始终无法看到最新上传的图片。然而该接口在另外一个场景下是正常的，这也是我提供这个接口给他的原因。

传了图片没被搜到？是不是上传后生成的图片 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 这个字符串。

而传空字符串，就不会改变语义，能匹配到所有数据。