登入狀態的資料蒐集往往需要多個帳號，而遇到限流時，問題不一定出在腳本本身。把關聯風險拆成裝置特徵、網路出口、工作階段狀態與請求節奏四個變數來看，更容易看清哪些因素能長期控制。
電商資料蒐集大致分成兩類：不需要登入的公開頁面蒐集，以及需要登入狀態的蒐集，例如查看競品後台資料，或取得個人化顯示後的結果。
前一類通常把頻率控制好就足夠。後一類一旦涉及多個帳號，真正決定成敗的就不再是腳本寫得多聰明，而是這些帳號能不能各自獨立存在。這一層沒有做好，限流和封鎖看起來就像隨機發生，改腳本、降頻率或換 selector 都不會有改善。
風險從哪裡來
平台判斷幾個帳號是不是由同一方操作，會進行交叉驗證：網路位址、瀏覽器與裝置特徵、Cookie 與工作階段資料，以及操作習慣。任何一類高度重疊，都可能讓這些帳號被歸到同一個操作方之下。
這裡要先畫出一條界線。判定邏輯會持續更新，依賴臨時技巧去對抗，效果短暫而成本很高，因此下面不討論如何繞過風控。值得討論的是另一件事：把風險來源釐清之後，哪些是我們能控制、也能長期維持穩定的變數？這些變數決定的是，多個合法帳號之間會不會互相牽連。
裝置與瀏覽器特徵
最容易出問題的組合之一，是在同一台電腦上開多個視窗登入不同帳號。即使清除快取或使用無痕模式，這些視窗仍然共享同一套系統環境與瀏覽器資料，特徵依舊重疊，平台看到的是同一台裝置反覆切換身分。
可控的做法是讓每個帳號都有自己的環境：一個帳號對應一個獨立環境，fingerprint、Cookies 與本機儲存彼此分離。關鍵是把這個環境固定給帳號，而不是每次啟動都隨機產生一套。隨機組合常常彼此矛盾，時區、語言、解析度與 UA 可能對不上，看起來反而比穩定不變的設定更異常。
說到底，穩定來自一致性，不是隨機性。
網路出口
出口要和帳號綁定：一個環境一個出口，而且出口地區要和帳號資料、時區、語言整套一致。多個帳號即使環境分開，卻共用同一個出口，前面的隔離效果也會大幅降低。
出口也要相對穩定。頻繁更換地區，會讓帳號所在地這個訊號變得難以解釋。選擇出口時，住宅類位址通常比資料中心位址更像一般使用者的正常存取；同時也要避免使用已被大量使用過的位址，因為這類位址本身可能已經受到更密切的監控。
Cookies 與工作階段
工作階段狀態本身就是一份身分紀錄。多個帳號共用同一份 Cookies 或本機儲存，等於直接在它們之間建立連結，再乾淨的環境隔離也無法抵消。
新環境裡的工作階段也不適合一開始就高強度使用。先累積一段正常瀏覽形成的歷史，再逐步提高工作量。這個原則在資料蒐集以外也同樣成立：帳號是否具有使用歷史，會直接影響它能合理承受多少活動。
請求節奏
請求密度是行為層面的訊號。腳本常見的特徵是節奏過於整齊：固定的存取間隔、固定的頁面順序，而且從不出現蒐集之外的行為。這種規律不是加一些隨機數就能解決，真正的問題在於整體量級。
可控的方向是把工作量維持在合理範圍內：錯開不同帳號的執行時段，不要讓所有帳號同一時間一起跑到最大負載，頁面之間保留合理間隔，並區分高優先與低優先的蒐集任務。界線其實很清楚：不能因為你的蒐集讓對方服務承受壓力。反過來說，任何以影響對方服務為代價換來的蒐集速度，都不是合理的做法。
為什麼每個帳號固定環境比隨機切換更穩定
隨機切換的動機是每次都換個樣子，但關聯判定看的是各個維度之間是否穩定，以及訊號彼此是否矛盾。一個帳號今天從這裡出去，明天從另一個地方出去，每次的特徵組合都不同，這種不一致本身就是異常訊號。
固定環境的邏輯正好相反。帳號從註冊開始就有一套一致的身分：固定環境、固定出口、彼此相符的時區與語言，以及逐步累積的工作階段歷史。這種一致性維持得越久，活動就越容易像一般使用者。環境層的價值就在這裡：提供長期穩定，而不是花俏的變化。
這也解釋了為什麼蒐集腳本不應該自己管理瀏覽器執行個體。環境要能獨立排程，才能替不同帳號分配專屬環境；環境狀態要能查詢，才能發現異常環境與已失效的帳號；環境要能回收，否則長期執行會累積大量 zombie instance；蒐集任務重試時往往需要換一個環境，這也只有在環境可以獨立排程時才做得到。在這類架構中，PurpleMark 就是環境資源這一層。腳本只負責蒐集邏輯，身分與資源則交給環境層。
合規界線
最後這幾點比前面任何最佳化都重要。
遵守目標網站的服務條款與 robots 規則。許多電商平台會在條款中明確限制自動化存取，因此開始之前應先確認你的使用方式是否被允許。只蒐集公開的商品、價格與庫存資訊，不蒐集個人資訊。不繞過技術保護措施；遇到 CAPTCHA、加密介面等防護時，應調整蒐集策略或申請授權，而不是想辦法破解。控制請求頻率，無論手上有多少帳號，都不應影響對方服務的正常運作。
這些討論的前提，是多個合法帳號如何各自獨立、互不干擾，而不是如何規避平台規則。前者是營運衛生，後者是另一回事。
