编码问题为什么在蜘蛛池里更容易被忽略
入口页通常是批量生成、批量部署的：模板一套、内容一套、服务器和 CDN 又各有一套配置。模板里 meta 写的是 UTF-8，服务器返回的响应头可能是 GBK；本地测试一切正常，上线后经过缓存层或对象存储转码又变了样。人眼看页面是正常的，因为浏览器容错能力强，会自己猜编码；而蜘蛛拿到的往往只是响应头加上一段原始字节，能猜的余地小得多。
结果就是：页面能抓，链接能跟，但标题、锚文本、正文里出现问号串、方块或者一串看不懂的字符。这类问题不会让抓取立刻停下来，却会让入口页里那些本来用来说明链接含义的文字失去作用。
三类最常见的编码异常
1. HTTP 响应头与 meta 声明不一致
服务器返回的 Content-Type 里写着 charset=gbk，页面源码里却声明 utf-8，或者两边都没写。蜘蛛一般会优先参考响应头，于是同一段字节被按错误的规则解码。这种情况在老站迁移、程序换框架时特别常见，从前台看几乎发现不了。
2. BOM 与首字节垃圾
UTF-8 BOM 是文件开头的三个不可见字节，保存时被悄悄加上。它本身不报错，但会让文档在 DOCTYPE 之前多出一段内容。更常见的是模板文件开头多了一个空行、一个空格，或者某段脚本在输出前打印了调试信息，这些都会挤到页面最前面，干扰蜘蛛对头部的解析。
3. 压缩、转码与拼接环节出错
gzip 或 brotli 压缩与 Content-Encoding 声明不匹配、CDN 缓存了旧版本、程序按字节截断中文（比如用 substr 截一个汉字的一半），都会产生半个字的乱码。这类问题通常只在部分 URL 上出现，抽样检查时容易漏掉。
蜘蛛遇到乱码时会怎样
不要指望它会帮你猜。多数情况下蜘蛛仍然会抓取页面、解析 HTML 结构、跟着链接走，但文字类信息可能被丢弃或者替换成占位符。这意味着入口页里的锚文本和上下文说明基本失效；如果乱码出现在页面头部，还可能影响它对页面标题、语言属性的判断。这里没有“一定不收录”这类说法，只是入口页的表达能力被白白浪费了。
排查顺序：从响应头到源码
- 用 curl 查看响应头，确认 Content-Type 是否带 charset，取值是多少。
- 查看页面源码前 200 字节，确认 meta charset 的位置和取值，是否在首屏范围内。
- 用十六进制方式看文件开头几个字节，确认有没有 BOM。
- 核对 Content-Encoding 与实际压缩方式是否一致，必要时绕过 CDN 直接访问源站对比。
- 最后再查程序层：数据库连接编码、模板文件编码、字符串截断函数、输出缓冲。
日常维护建议
- 全站统一 UTF-8，响应头和 meta 都写 utf-8，两边保持一致。
- 模板文件保存时去掉 BOM，脚本文件不要在结尾留空行或多余字符。
- 截取中文字符串用支持多字节的函数，不要按字节切。
- 缓存层不要自动转码，刷新策略跟着内容更新节奏走。
- 入口页上线后固定抽样抓取几个 URL，检查标题和锚文本是否正常显示。
编码不影响你能不能搭起一个蜘蛛池，但它影响蜘蛛能不能读懂你在页面上写的那句话。