在做蜘蛛池时，一個常被忽略的問题是：入口頁上的連結，蜘蛛到底看不看得见。很多人抱怨“連結放了上千條，抓取却没動静”，排查到最後發現頁面主体是客戶端渲染的，源碼里只有一段脚本，連結全在 JS 执行之後才出現。
抓取和渲染是两條不同的路径
搜尋引擎爬虫拿到一個 URL 之後，第一步是抓取原始 HTML，第二步才可能把它丢進渲染队列，用類似浏览器的环境执行 JS。這两步的代價完全不同：抓取便宜、並發高；渲染昂贵、排队久，而且通常有單獨的配額。對蜘蛛池這種量大、頁面生命周期偏短的场景来说，能不能在第一步就让連結可见，几乎决定了整套流程的效率。
三種渲染方式對連結發現的影响
纯静態 HTML
連結直接寫在返回的源碼里，爬虫不需要渲染就能發現並繼續跟進。這是蜘蛛池入口頁最省事、也最稳定的方式，尤其当入口頁本身只是一個連結中轉层时。
服務端渲染
服務端把完整的 HTML 拼好再返回，對爬虫来说和静態頁面几乎没有区別。差別主要在服務器成本和缓存策略上：如果每個請求都實时渲染，入口頁多了以後容易拖慢响應速度，反而影响抓取效率。
客戶端渲染
源碼里只有容器和脚本，連結要等 JS 执行後才插入 DOM。爬虫能不能看到，取决于它是否愿意為這個頁面花渲染配額。對權重低、内容薄的新入口頁来说，被渲染的概率往往並不高。
蜘蛛池场景下的取舍
- 入口頁優先静態化。它的核心职责是让連結被發現，不是展示复杂交互，没必要為了前端体驗牺牲可见性。
- 混合渲染要有兜底。如果确實需要 JS，至少在首屏 HTML 或 noscript 里保留一份可点击的連結列表。
- 减少非必要的渲染触發。轮播、懒加载、無限滚動這類交互會把連結藏在事件之後，蜘蛛未必會去触發。
- 注意渲染請求的延迟。渲染型抓取往往比普通抓取晚几天甚至更久，連結的时效性會打折扣。
几個常见的誤区
- “浏览器能看到就等于蜘蛛能看到”。你打開頁面看到連結，是因為浏览器执行了 JS；爬虫未必有同样的待遇。
- “加了预渲染就萬事大吉”。预渲染服務本身也可能被限速或识別，效果要從日誌里驗證，而不是想当然。
- “連結在源碼里就行”。如果連結是靠 JS 拼出来的地址，或者被注释包裹、被 CSS 隐藏，實际也不會被正常跟進。
怎么自查
- 用 curl 或查看網頁源代碼（不是审查元素），確認連結是否出現在原始 HTML 中。
- 關閉浏览器 JS 再打開頁面，能点到的連結才算真正對爬虫可见。
- 對照服務器日誌，看抓取請求里是否出現了 JS、CSS 等静態资源的拉取，這通常意味着渲染型抓取發生過。
- 對比源碼中的連結數與浏览器中實际渲染出的連結數，差异越大，說明對渲染的依赖越重。
蜘蛛池的效率，很多时候不取决于你放了多少連結，而取决于這些連結在第几次請求里就已经可见。