从你遇到的现象来看，这个问题大概率是后端对URL查询参数的解析或过滤逻辑出了问题，具体可以从这几个方向排查：

• 参数解析逻辑存在bug：有些自定义或者老旧的后端参数解析代码，在处理带=的额外参数时容易出错。比如可能错误地将整个查询串按某个规则截断，或者遍历参数时遇到带=的未知参数就停止解析，导致原本的keywords=GTX127375没有被正确读取；还有一种可能是，后端把所有带=的参数都当成了搜索条件，尝试用utm_source去匹配数据库字段，自然搜不到结果。

• 参数白名单的异常处理有缺陷：如果后端只允许search_type和keywords这两个参数（也就是所谓的参数白名单），正常来说应该忽略其他参数，但可能当白名单外的参数带有=时，后端的异常处理逻辑“走偏”了——比如直接返回空结果，而不是跳过非法参数继续处理合法的；或者清理非法参数时误删了后面的合法参数，导致keywords丢失，搜索自然为空。

• 不安全的SQL拼接逻辑：虽然这不太推荐，但有些项目会直接把URL参数拼进SQL查询。如果是这种情况，加入utm_source=google后，SQL可能变成了WHERE search_type='searchAntibody' AND keywords='GTX127375' AND utm_source='google'，而你的数据库里根本没有utm_source这个搜索字段，结果当然是空的。

几个快速验证的小方法 #

你可以做几个测试来定位具体原因：

1. 试试加其他带等号的无关参数，比如&test=abc，看是不是也返回空结果；
2. 把utm_source挪到参数最前面，比如https://www.funakoshi.co.jp/searches?utm_source=google&search_type=searchAntibody&keywords=GTX127375，如果能正常返回结果，说明是参数解析顺序相关的bug；
3. 查看后端的请求日志，看看传入的参数是否被正确接收，有没有报错信息。

内容的提问来源于stack exchange，提问作者Patrick Harris