先说结论
多數抓取器對一次 HTTP 响應的解析字节數是有上限的，具体數值各家不同，也没有公開承诺。這意味着入口頁 HTML 越大，排在後面的連結被解析到的概率越低——不是一定丢，而是風險随体积上升。
為什么會有讀不完這件事
抓取不是把文件下载下来慢慢讀完這么简單。為了控制成本，抓取器通常會在下载到一定字节數後停止讀取，或者只在有限的预算内解析連結。
- 下载体积上限：超過的部分直接被丢弃，後面的連結從未進入解析队列。
- 解析预算：即使全文拿到了，連結抽取也可能只處理前面一段。
- 渲染预算：需要执行 JS 才出現的連結，通常有單獨的渲染配額，和静態 HTML 里的連結不是一回事。
体积大不等于一定抓不到，但在其他條件相同时，連結越靠後，被發現的确定性越低。
哪些寫法容易把体积撑大
- 把图片、字体以 base64 内联進 HTML，一段就是几十上百 KB。
- 頁面上直接輸出大量 JSON 資料，比如整站導航或商品列表的原始資料。
- 模板里带着大段注释和早已废弃的隐藏区块，一直没清理。
- 几千條連結平铺在一個頁面，既不分頁也不分层。
前三種是纯粹的浪費：体积涨了，連結數量却没變。第四種更麻烦，是連結總量過大和單條連結位置過靠後這两種問题叠加在一起。
怎么判断自己有没有踩坑
- 先用命令行工具量一下入口頁的實际字节數，開啟压缩前後各看一次，心里有個基數。
- 打開頁面源碼，找到你最想被抓的那几個連結，看它們在文件里的字节偏移大概排在第几成。
- 對照服務端日誌的抓取记錄：如果蜘蛛反复来訪，目标 URL 却一直没出現，而入口頁体积明顯偏大，就值得怀疑。
- 可以做個小對照測試：临时把入口頁拆開，只保留前一半連結，观察目标 URL 的發現情况有没有變化。
調整方向
- 連結前置：把最重要的目标 URL 放在正文靠前的位置，而不是塞在最底部。
- 减法優先：能外鏈的资源不要内联，能删的資料不要輸出，模板里的冗余注释清干净。
- 分块：几千條連結拆成多個入口頁，每頁控制在几百條以内，用索引頁或分頁把它們串起来。
- 兜底：sitemap 和頁面連結並不冲突，体积偏大的站点尤其值得让 sitemap 分担一部分發現职责。
- 驗證：改完不會立刻见效，抓取频率和缓存都影响重抓节奏，观察周期按周算更合理。
几個常见的誤解
有人以為体积上限是個固定的官方數字，查到就能卡着寫。實际上不同抓取器、不同内容類型差別很大，而且會調整，卡邊界是最不划算的做法。
也有人把责任全推给体积。連結没被抓到，同样常见的原因還有：連結是脚本生成的、頁面返回了非 200 狀態、robots 規則挡了路径、目标站自身响應超时。体积只是其中一種可能，排查时要放在一起看。
落地做法其實就一句话：入口頁保持轻，重要連結靠前，連結數量和頁面体积都留出余量，剩下的交给 sitemap 和日誌去驗證。