编码问题为什么值得单独拎出来说
蜘蛛抓到一个入口页，拿到的是字节流，它要按某个规则把字节还原成字符，才能判断这页在讲什么、标题是什么、有没有和目标页相关的词。如果还原过程出错，页面在蜘蛛眼里可能就是一堆乱码或者空白。人眼在浏览器里看到的是正常的，是因为浏览器做了容错和猜测；抓取端不一定有同样的容错策略，也不一定会像浏览器那样反复试。
所以编码不是排版细节，它直接影响页面能不能被读懂。
三种最常见的情况
1. 响应头和 meta 声明不一致
服务器返回的 Content-Type 里写了 charset=gbk，页面 meta 里却写着 utf-8，两边打架。这时候按哪个走取决于具体实现，可能是响应头优先，也可能是先读一段字节再猜。结果就是同一批入口页里，一部分正常、一部分乱码，排查时很费劲。
建议统一：要么全站 UTF-8，要么全站 GBK，别混用。响应头、meta、文件本身保存的编码三者保持一致。
2. BOM 头
UTF-8 文件如果带了 BOM，会在文件最前面多出三个不可见字节。有些拼装页面或输出的程序也可能重复写入 BOM，导致页面开头出现几个奇怪字符，甚至把 doctype 顶到后面去。解析时偶尔会因此判错文档类型，或者把 head 部分读乱。
3. 数据库和模板各写各的
入口页内容通常是从数据库、接口、模板里拼出来的。数据库连接设成一种编码，模板文件是另一种，程序输出时又转了一次，三次转换里错一次，页面就会出问号、方块或者连续的问号串。这种问题往往只在包含中文的字段上出现，英文数字正常，所以更隐蔽。
乱码之后会发生什么
- 关键词对不上。页面上本来有的词变成乱码，抓取端做主题判断时就少了一个依据。
- 模板重复度看起来更高。正文都成了乱码，剩下的可区分内容就只剩结构和标签，页面之间的差异被压得更小。
- 标题和锚文本失效。标题乱码会影响蜘蛛对这条链接指向哪里的判断。
- 正文被判为无意义。有些处理流程会直接丢弃看不懂的文本块，页面等于空壳。
这几点叠加起来，表现就是抓取意愿下降、回访变少，而你在浏览器里看页面却是正常的。这正是编码问题麻烦的地方。
一份自检顺序
- 用 curl 或抓取工具直接取一次原始响应，先看响应头里的 charset。
- 把返回的字节按响应头声明的编码解码，看中文是否正常。
- 再按 UTF-8 解一次，对比两次结果，判断哪边是对的。
- 检查文件是否带 BOM，尤其是用某些编辑器另存过的模板。
- 检查数据库连接、表、字段、模板文件的编码设置是否一致。
- 抽查一批页面而不是只看首页，因为拼接路径不同的页面表现可能不一样。
顺带说一句首屏
编码正确之后，还要看首屏有没有有效内容。有些入口页把大段模板导航、广告位或者空容器放在最前面，真正的内容要往下滚动才出现。抓取端拿到的 HTML 顺序和你看到的视觉顺序可能不同，如果正文被塞在一堆重复结构后面，判断页面的有效信息就会更费劲。把关键的一句说明放在靠前位置，比堆装饰性模块更实际。
几个可以固定下来的习惯
- 新入口页统一 UTF-8，包括数据库、模板、响应头。
- 上线前用脚本抽查原始响应，别只靠浏览器目测。
- 批量生成流程里加一步编码校验，发现异常就拦下来。
- 把编码检查写进日常巡检，和状态码、响应时间一起看。
编码问题不会让页面立刻消失，但它会让页面在蜘蛛眼里变得模糊。模糊的页面，得到的关注通常也少。