你写了个脚本去某个站点搜索，英文关键词一搜一个准，换成中文关键词，返回的结果永远是 0 条。试了好几个不同的中文词，全是空。你开始怀疑「这个站是不是压根没有中文资源」，甚至怀疑站点封了你。
现象
- 同一个接口，
?q=python有结果，?q=中文返回[]或「共 0 条」； - 没有任何报错，程序跑得干净利落，就是「没有结果」；
- 手动在浏览器里输入同样的中文关键词，能搜出东西。
最后这一条是关键对照：同一个站、同一个词，浏览器有结果、脚本没结果。 说明问题不在站点，在脚本怎么把关键词发出去。
根因
问题出在查询串的编码：你和站点，对「这段中文该用哪种字节表示」的假设不一致。
一个 URL 里不能直接放中文，必须先把中文按某种字符编码转成字节，再对这些字节做 URL 编码（也叫百分号编码，%E4%B8%AD 这种形式）。流程是：
中文关键词 --(字符编码)--> 字节 --(URL 编码)--> %XX%XX%XX
关键在第一步——用哪种字符编码。如果站点按 GBK 解码查询串，而你发出去的是按 UTF-8 编码的字节，那么站点的解码器会把你的字节「翻译」成完全不同的字符，自然匹配不到任何内容，返回 0 条。
反过来也一样：如果站点是 UTF-8，而你的库默认用了 GBK（在某些 Windows 环境下会发生），同样对不上。
这就是「编码对不上」的典型症状：不报错、不崩溃，只是静默地搜不到。 因为从站点的角度看，你发来的确实是一个合法但毫无意义的查询串。
解决
原则：搜索参数一律先用 UTF-8 编码，再做 URL 编码。
用 Python 标准库时，显式指定编码：
import urllib.parse
params = {'q': '中文关键词', 'page': 1}
query = urllib.parse.urlencode(params, encoding='utf-8')
url = f'http://example.com/search?{query}'
print(url)
# http://example.com/search?q=%E4%B8%AD%E6%96%87%E5%85%B3%E9%94%AE%E8%AF%8D&page=1
urlencode 的 encoding='utf-8' 参数就在这里起作用——它决定「中文 → 字节」这一步用哪种编码。默认值在不同 Python 版本/平台上可能不同，所以显式写死 UTF-8 是最稳的。
如果确认目标站点就是 GBK 的老站，那就按它来：
query = urllib.parse.urlencode(params, encoding='gbk')
然后用 curl 或开发者工具对照一下：在浏览器里搜一次，看 Network 面板里实际发出的 URL 长什么样，把它的百分号编码复制出来和自己拼的比一比，一眼就能看出用的是 UTF-8 还是 GBK。
延伸与预防
调试这类问题时，有一个万能的对照法：用浏览器发一次同样的请求，抓下它实际发出的 URL。
浏览器的行为是「对的基准」，因为它一定和站点兼容。你把自己的 URL 和浏览器的 URL 摆一起比，如果百分号编码不同（比如同样一个「中」，一个编成 %E4%B8%AD、另一个编成 %D6%D0），那就确诊是编码不一致。
%E4%B8%AD 是 UTF-8 的「中」，%D6%D0 是 GBK 的「中」——记住这个对比，你可以快速判断任何一段查询串用的是哪种编码。
再往上一层，这条坑归入一个大类问题：「空结果」和「报错」是两种完全不同的失败。
- 报错说明请求到达了、被拒绝了，问题多半在参数合法性或权限；
- 空结果说明请求成功了、只是没匹配到，问题多半在参数的值或编码。
遇到空结果，不要去查网络和权限，先怀疑「我发出去的东西，对方是不是理解成了别的东西」。搜不到不一定是没有，也可能是你发的词，对方根本认不出来。