curl -s 'http://127.0.0.1:8000/search?q=%E7%BA%A2%E7%83%A7+%E8%82%89' | head -c 200
python3 -c "from urllib.parse import unquote,unquote_plus;print(repr(unquote_plus('a+b')),repr(unquote('a+b')))"
搜索 红烧 肉 时列表空结果，日志里 keyword=红烧+肉。同一个词改用表单提交就正常，两个入口只有拼接方式不同。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，application/x-www-form-urlencoded 里空格约定编码成 +，按这套规则解才还原成空格。部分框架对 query 只做 percent-decode，+ 原样留着，关键词里就凭空多了一个字符。
围绕「URL 空格加号」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
处理上按这个顺序：拼 query 用 encodeURIComponent 空格会变成 %20 不产生歧义；后端解码前先确认框架是否把 + 当空格处理；两个入口用同一个搜索词 对比日志里的原始 URL；把 + 和 %20 两种写法都写进用例。
改完只确认一件事：同一个搜索词从两个入口进来 日志里的 keyword 完全一致 都能搜到结果。