先说结论
多数抓取器对一次 HTTP 响应的解析字节数是有上限的，具体数值各家不同，也没有公开承诺。这意味着入口页 HTML 越大，排在后面的链接被解析到的概率越低——不是一定丢，而是风险随体积上升。
为什么会有读不完这件事
抓取不是把文件下载下来慢慢读完这么简单。为了控制成本，抓取器通常会在下载到一定字节数后停止读取，或者只在有限的预算内解析链接。
- 下载体积上限：超过的部分直接被丢弃，后面的链接从未进入解析队列。
- 解析预算：即使全文拿到了，链接抽取也可能只处理前面一段。
- 渲染预算：需要执行 JS 才出现的链接，通常有单独的渲染配额，和静态 HTML 里的链接不是一回事。
体积大不等于一定抓不到，但在其他条件相同时，链接越靠后，被发现的确定性越低。
哪些写法容易把体积撑大
- 把图片、字体以 base64 内联进 HTML，一段就是几十上百 KB。
- 页面上直接输出大量 JSON 数据，比如整站导航或商品列表的原始数据。
- 模板里带着大段注释和早已废弃的隐藏区块，一直没清理。
- 几千条链接平铺在一个页面，既不分页也不分层。
前三种是纯粹的浪费：体积涨了，链接数量却没变。第四种更麻烦，是链接总量过大和单条链接位置过靠后这两种问题叠加在一起。
怎么判断自己有没有踩坑
- 先用命令行工具量一下入口页的实际字节数，开启压缩前后各看一次，心里有个基数。
- 打开页面源码，找到你最想被抓的那几个链接，看它们在文件里的字节偏移大概排在第几成。
- 对照服务端日志的抓取记录：如果蜘蛛反复来访，目标 URL 却一直没出现，而入口页体积明显偏大，就值得怀疑。
- 可以做个小对照测试：临时把入口页拆开，只保留前一半链接，观察目标 URL 的发现情况有没有变化。
调整方向
- 链接前置：把最重要的目标 URL 放在正文靠前的位置，而不是塞在最底部。
- 减法优先：能外链的资源不要内联，能删的数据不要输出，模板里的冗余注释清干净。
- 分块：几千条链接拆成多个入口页，每页控制在几百条以内，用索引页或分页把它们串起来。
- 兜底：sitemap 和页面链接并不冲突，体积偏大的站点尤其值得让 sitemap 分担一部分发现职责。
- 验证：改完不会立刻见效，抓取频率和缓存都影响重抓节奏，观察周期按周算更合理。
几个常见的误解
有人以为体积上限是个固定的官方数字，查到就能卡着写。实际上不同抓取器、不同内容类型差别很大，而且会调整，卡边界是最不划算的做法。
也有人把责任全推给体积。链接没被抓到，同样常见的原因还有：链接是脚本生成的、页面返回了非 200 状态、robots 规则挡了路径、目标站自身响应超时。体积只是其中一种可能，排查时要放在一起看。
落地做法其实就一句话：入口页保持轻，重要链接靠前，链接数量和页面体积都留出余量，剩下的交给 sitemap 和日志去验证。