缓存為什么會變成蜘蛛池的變量
蜘蛛池的入口頁通常數量大、更新频繁，很多站点為了扛住集中抓取，會在前面加一层 CDN 或反向代理缓存。這时候蜘蛛拿到的内容，不一定是你源站此刻正在輸出的那一份。對做 URL 發現和站点运营的人来说，麻烦在于：你改了入口頁的連結结构，蜘蛛那邊可能還在讀舊版本，于是抓取路径看起来毫無變化。
先把概念理清楚：缓存不是“好”或“坏”，它只是一種“把某一份响應多停留一會儿”的机制。關键是你要知道哪一份被停留了、停留多久、對谁停留。
入口頁可能出現的三種缓存狀態
- 完全回源：每次請求都打到源站，蜘蛛拿到的一定是最新版，但服務器压力最大。
- 邊缘命中：CDN 节点直接返回缓存副本，速度快，但你更新後的一段時間里，蜘蛛讀到的仍是舊内容。
- 混合狀態：不同节点、不同地区、不同 UA 命中情况不一样，同一批入口頁在蜘蛛眼里版本混乱。
第三種最容易出問题。你在一台机器上测得好好的，蜘蛛從另一個出口訪問却拿到了舊缓存，于是你會得到互相矛盾的抓取日誌。
几個常见的誤区
改了源站，蜘蛛就该立刻看到
缓存有效期没到，或者 CDN 没被通知刷新，蜘蛛就看不到。尤其是给静態入口頁设了較長 TTL 的时候，這種延迟會非常直观。
把爬虫都当成普通訪客
有些配置會给移動端、PC 端返回不同模板，或者根據 UA 走不同逻辑。如果缓存键没有把這些维度拆開，就會出現“A 蜘蛛拿到 B 版本”的情况。這類問题不會报错，只會让入口頁里出現的連結莫名其妙。
只刷首頁，不刷入口頁
入口頁數量多、路径深，往往不在常規刷新范围内。批量更新後如果只刷了几個主入口，剩下的會長期停在舊版本上。
配置上的几個務實做法
- 把入口頁的缓存時間设短一些，或者用較短 TTL 配合回源校驗，让新鲜度和抗压能力之間有個折中。
- 缓存键要把影响輸出的维度算進去：域名、路径、查询參數、设备類型，必要时再加 UA 分類。否則命中就是错位命中。
- 批量改版後主動做一次缓存刷新，把入口頁目錄一起提交，而不是逐個手点。
- 如果入口頁内容本身很少變化，長缓存可以接受；但要确保新增連結尽快出現在被缓存的那份頁面里，否則 URL 發現會滞後。
- 给抓取量大的路径單獨设策略，不要和全站預設策略混在一起。
判断缓存有没有拖後腿，最简單的办法是：在源站加一個临时标记（比如只在回源时才出現的注释或响應头），然後看蜘蛛的請求结果里有没有它。
怎么观察和驗證
看日誌的时候，別只看狀態碼。把相同 URL 的响應長度、Last-Modified、内容摘要拉出来對比，能比較快地判断是不是有多份版本在同时被人讀。如果發現某個入口頁被讀到的内容和你预期不符，先查缓存，再查是否被中間层改寫，最後才怀疑模板本身。
需要提醒的是，把缓存配好只是让蜘蛛“看到该看到的東西”，它並不决定蜘蛛是否来、是否繼續往下走。入口頁能不能被稳定讀到，是後續所有观察的前提，但它本身不等于效果。