批量查詢真正的瓶頸是速率，不是速度
直覺上會以為批量查詢的挑戰是「跑得夠快」。實際上單筆查詢大概一到兩秒，五百個網域就算完全串行也只要十幾分鐘——那不是問題。真正的瓶頸是上游願意讓您查多快。
備案資料的來源最終都指向工信部，中間可能經過雲服務商的查詢介面或第三方資料庫，而每一層都有自己的速率限制。我們實測過一個公開的免費介面，它的展示金鑰大約每 20 秒才允許一次查詢——用那個跑五百個網域要將近三小時，而且中途只要一次沒退避就會被連續拒絕。 下表是幾種常見做法的取捨。
| 做法 | 實際上會遇到什麼 | 適合的規模 |
|---|---|---|
| 人工逐一查詢 | 可行但耗時，而且不會有人真的每月做一次 | 十個以內 |
| 自己寫爬蟲打官方查詢頁 | 要處理驗證碼、版面改版與封鎖，維護成本遠高於預期 | 不建議 |
| 接免費公開介面 | 速率限制嚴格，冷門網域覆蓋率不足，錯誤回報不可靠 | 幾十個，可容忍漏查 |
| 接付費查詢 API | 需要確認配額、錯誤語意與資料來源是即時或快照 | 數百到數千 |
| 自建快取層加排程 | 上游仍有限制，但可以攤平，並且能偵測變動 | 持續監控的場景 |
第二列是多數人一開始會選、然後撞牆的那一種。自己寫爬蟲打官方查詢頁看起來最省錢，但驗證碼、版面改版與封鎖都要自己處理，而且對方每改一次版您就要修一次——這份維護成本通常在三個月後才會被認真計算。
三個實作上的重點
這三件事決定您的批次跑得完、還是跑一半就被擋。
- 退避要讀對方給的數字 被限流時，很多介面會在錯誤訊息裡明確寫出要等多久。固定間隔重試會持續撞牆，而讀取那個數字再等對應秒數，一次就能過。我們自己測試時第一輪就是因為固定 1 秒間隔，19 個網域有 14 個被限流——換成讀取對方指定的秒數之後，同一批全部跑完。
- 快取要分清楚「查過」和「查到」 備案狀態變動不頻繁，所以快取很有效。但要注意：失敗的查詢不能當成結果快取。如果上游逾時被存成「無備案」，那個錯誤會留在您的資料裡，而且因為有快取，之後也不會再查一次。快取的鍵應該包含查詢是否成功，失敗的只重試不寫入。
- 真正要存的是變動，不是狀態 存「目前狀態」只能回答「現在如何」。存每次查詢的結果與時間戳，才能回答「什麼時候掉的」——而那才是您真正需要的告警。備案消失的時間點通常比發現的時間早好幾週，有歷史記錄才查得出來是哪次改動造成的。
錯誤語意：批量查詢最容易出事的地方
單筆手動查詢時，回應看起來怪您會自己發現。批量跑的時候沒有人在看——所以錯誤必須在結構上可區分，否則它會安靜地變成資料。
這不是假設性的風險。我們實測一個公開介面時，它對 google.com 回傳的是 HTTP 200、code 200，而 icp、unit 等欄位的值全部是字串「查询失败」。寫成 if resp["icp"]: mark_as_filed() 的程式會把 google.com 標記為已備案，並把那四個字存成備案號。
所以接任何資料來源之前，先確認三種情況在回應上分得開：確定有備案、確定沒有備案、這次查不到。第三種必須有自己的表達方式——獨立的狀態碼或欄位，而不是塞進資料欄位裡。分不開的來源，不能直接接進會寫入資料庫的流程。這一點與資料準不準是兩回事，我們在備案查詢工具實測那篇有完整的測試過程。
自建還是接 API
如果您要查的是幾十個網域、每季一次，自己寫個腳本打免費介面、加上退避與重試就夠了，不需要付費。這篇前半講的實作重點足夠讓它穩定運作。
需要考慮付費方案的通常是三種情況：網域數量到數百以上、需要的是持續監控而不是一次性盤點、或是冷門網域查不到的比例太高。最後一項最容易被低估——免費來源在知名網域上表現正常，在冷門網域上可能大量漏查，而冷門網域往往正是您要查的那些。
三個層次的規劃
依序決定，可以避免過度設計：
一、先確定查詢的頻率需求
一次性盤點和持續監控是兩種系統。盤點跑完就結束，不需要資料庫；監控需要歷史記錄、變動偵測與告警。先確定是哪一種，再決定要蓋多少東西。
二、估算批次需要多久跑完
用「網域數 × 每筆最小間隔」估算。如果結果超過您的排程窗口，問題不是加機器能解的——那是上游速率限制，要靠快取、分批、或換資料來源處理。
三、決定查不到的時候怎麼辦
這是最常被略過的設計決定。查不到要重試幾次、重試完還是失敗要不要告警、以及絕對不能把失敗寫成「無備案」。先想清楚，比事後清理資料容易得多。
接任何備案查詢 API 前該確認的三件事
不論是我們的還是別人的，這三項決定它能不能接進自動化流程：
- 速率限制、配額與逾時行為 每秒與每日上限各是多少、超過回什麼、上游逾時的時候是回錯誤還是回「無備案」。最後這一項最容易在上線後才踩到。
- 失敗與「無備案」在回應上如何區分 要看實際的回應結構，不是文件上的描述。確認錯誤有獨立的狀態碼或欄位，而不是被塞進備案號欄位裡。
- 資料是即時查詢還是快照 這決定冷門網域查不查得到，也決定備案失效之後多久才會反映出來。要求對方說明快照的更新頻率與覆蓋範圍。
小結
批量查詢備案狀態的難點不在速度，在速率限制與錯誤語意。前者決定批次跑不跑得完，後者決定跑完之後那份資料能不能信。實作上三件事最關鍵：退避時讀對方給的秒數、失敗絕對不要當成結果快取、以及存變動而不只是存狀態。
規模不大就自己寫，這篇的做法足夠。如果您的網域數量到數百以上、或是需要持續監控並在備案消失時收到告警，歡迎來信說明用量與使用情境，我們再看怎麼配合。