「被封」通常不是一件事
腳本昨天還好好的，今天開始返回空白、報錯，或者乾脆卡住。第一反應通常是換 IP、降頻率、改請求標頭——網上一搜全是這些。
但這些招數處理的是症狀。「被封」這個詞底下至少有四種完全不同的情況，處理方式互不相干，不分清就動手，多半是白花時間。
四種情況，先分清
一、單純的頻率限制
短時間請求太多，平台暫時拒絕你。特徵是過一段時間自己就好了，而且換個網絡環境立刻能存取。
這是四種裡最輕的，也是唯一「降低頻率慢慢跑」真的管用的一種。如果你的需求本來就不趕時間，把並發降下來、把週期拉長，通常就過去了。
二、頁面結構變了
這一種最危險，因為它經常不報錯。
目標站改版之後，你的選擇器還在跑，請求也是 200，但取到的欄位是空的。腳本不會告訴你有問題，數據照樣往表裡寫——等你發現的時候，可能已經累積了幾星期的空數據，而且分不清哪天開始的。
判斷方法不是看有沒有報錯，是看關鍵欄位的空值率。正常運行時某個欄位的填充率是穩定的，突然從九成掉到兩成，那不是數據源變了，是你的解析規則失效了。
建議每次跑完記錄各欄位的空值率並和上一次比對。這一步比任何異常告警都靈，而且成本幾乎為零。
三、內容本來就在登入牆後
你之前能取到，可能是因為平台當時對未登入存取更寬鬆。平台收緊之後，那部分內容不再對匿名存取開放。
這種情況換 IP、改請求標頭、降頻率都沒有意義，因為限制不在你這邊。Instagram、LinkedIn、Facebook 這幾個平台的未登入可見範圍在過去幾年一直在收窄，這是產品決策不是技術對抗。
碰到這一種，該做的是重新看需求：這個資訊有沒有別的公開來源能替代。三條可行的路和一條明確不該走的，寫在受限平台的數據怎麼辦。
四、你的採集行為被識別為自動化
平台判斷這些請求不是人發出來的，於是要求驗證或直接拒絕。
到這一步要先停下來問一個問題，而不是繼續想辦法：這件事到底該不該繼續做下去。
我們不做的那部分
站上寫死的邊界在這裡同樣適用，說清楚免得浪費彼此時間：
- 不繞過驗證碼、驗證機制或存取控制
- 不用客戶提供的帳戶登入採集，即使帳戶是你主動給的
- 不承接以規避平台風控為目的的需求
所以如果你的問題是「怎樣繞過去」，我們幫不上忙。我們能幫的是判斷這個需求能不能換一種方式滿足——多數情況下能，只是得先承認原來那條路走不通。
被封是不是該換方式的訊號
不一定。判斷標準不是「被封了沒有」，是這件事要不要長期重複做。
繼續自己做是對的：一次性需求、目標站結構簡單、你撞上的是第一種情況（限流）。降低頻率慢慢跑完就結束了，找人反而更慢。
該重新考慮的：這個採集要按週期長期跑，而你每個月都得花時間修它。第二種情況（結構變化）會反覆發生，因為目標站不會為你的腳本保持穩定。
關鍵在於維護成本不會消失，只會在你和別人之間轉移。一次性需求沒有這筆成本，所以適合自己做；一旦變成週期性的，這筆帳要重算。三條路各自適合甚麼，寫在自己寫、買現成工具，還是找服務商。
一個容易被忽略的成本
自己維護採集腳本，真正花掉的不是修的那兩小時，是發現問題的延遲。
結構變了、數據悄悄變空，你可能一星期後才注意到。這一星期的數據要麼作廢，要麼更糟——已經被拿去做了判斷。等到發現時，重跑歷史數據往往已經來不及，因為頁面上的內容已經變了。
這也是我們預設在交付裡帶完整率統計的原因：不是為了好看，是為了讓這種問題在第一次交付時就暴露出來，而不是三個月後。週期性項目還要提前定哪些事，寫在週期性數據更新要提前確認甚麼。
先做的三件事
如果你現在正卡在這上面，按順序做這三步：
- 換個網絡環境手動打開那個頁面。 能正常看到內容，說明是限流或自動化識別；看不到或要求登入，說明是登入牆，方向完全不同。
- 查關鍵欄位的空值率。 請求成功但欄位空了，那是結構變化不是被封，兩者的修法沒有關係。
- 問自己這件事還要做多少次。 一次，就慢慢跑完；每星期一次，那要算的是長期維護帳。
三步走完再決定投入。如果結論是這個需求本身走不通，那要改的是需求不是腳本——把目標網址發過來，評估階段就能給出這個判斷，不收費。