一、先搞懂：電商爬蟲的 3 大核心挑戰（比普通爬蟲更復雜的原因）

做電商爬蟲前，必須先明確「為什么難」—— 淘寶、京東、拼多多的反爬體系是「多層級、動態化、行為導向」的，絕非簡單的 UA 驗證或 IP 封禁：

1. 動態參數加密（最核心痛點）

三大平臺的商品列表頁 / 詳情頁接口，幾乎都有「動態生成的簽名參數」，且參數規則會定期更新：

• • 淘寶：sign「tk_trace」參數，依賴 cookie 中的tb_token「cookie2」，且與請求時間戳、用戶行為（如瀏覽軌跡）綁定；

• • 京東：sign「venderId」參數，需逆向 JS 中的md5加密邏輯，且同一 IP 下頻繁請求會導致 sign 失效；

• • 拼多多：anti_content參數（俗稱「防爬內容」），需模擬 APP 端的設備指紋（如imei「android_id」），PC 端幾乎無法爬取詳情頁。

1. 行為反爬（比參數更難對抗）

平臺會通過「用戶行為特征」識別爬蟲，而非僅看請求頭：

• • 無瀏覽軌跡：直接請求商品詳情頁，未先訪問首頁→分類頁→列表頁，會被判定為「異常請求」；

• • 請求頻率剛性：同一 IP / 賬號 1 秒內請求 > 5 次，或分頁爬取時跳過中間頁（如從第 1 頁直接到第 10 頁），會觸發臨時封禁；

• • 設備指紋不一致：PC 端爬蟲用固定 UA + 固定分辨率，或 APP 端爬蟲未模擬真實設備的「傳感器數據」（如加速度、陀螺儀），會被標記為「機器賬號」。

1. 數據動態性（爬取到的可能是「無效數據」）

電商商品數據有「實時性 + 地域性 + 賬號相關性」：

• • 價格：同一商品，不同地區（如北京 vs 上海）、不同賬號（新用戶 vs 老用戶）、不同時段（大促 vs 日常）價格可能不同；

• • 庫存：秒殺商品庫存每秒更新，爬取延遲 10 秒就可能導致數據失效；

• • 評價：平臺會對評價列表做「分頁動態加載 + 內容屏蔽」，直接爬取前 10 頁可能漏掉 80% 的真實評價。

二、分平臺實戰：淘寶 / 京東 / 拼多多的差異化爬蟲方案

三大平臺的反爬重點不同，不能用一套代碼通吃，需針對性設計方案 —— 以下是經過驗證的「低成本有效策略」（非黑產手段，聚焦合規爬取）：

1. 淘寶：優先用「PC 端模擬真實用戶 + cookie 池維護」

淘寶 PC 端的反爬強度低于 APP 端，適合中小規模數據爬取（如單品類商品監測）：

• 核心步驟：解決 cookie 鮮活度問題

① 初始 cookie 獲取：用「無頭瀏覽器（Playwright 優于 Selenium，資源占用低）」模擬真實用戶登錄（掃碼登錄，避免賬號密碼登錄被風控），獲取包含tb_token「cookie2」「uc1」的完整 cookie；

② cookie 池維護：每個 cookie 綁定 1 個 IP，每天用「低頻率行為（如瀏覽 3 個商品 + 收藏 1 個）」激活，避免 cookie 過期（淘寶 cookie 默認有效期 7-15 天，不激活會提前失效）；

③ 接口選擇：優先爬取「m 端（手機淘寶網頁版，https://m.tmall.com）」接口，參數加密比 PC 端簡單（如sign參數僅依賴時間戳 + cookie，無需逆向復雜 JS）。

• 避坑點：價格數據爬取

淘寶商品詳情頁的「原價」在 HTML 中可見，但「優惠價」需請求「https://mdskip.taobao.com/core/price/price.htm」接口，且需攜帶「商品 ID（itemId）+ 店鋪 ID（sellerId）+cookie」，否則返回「-1」（未登錄狀態）。

2. 京東：逆向「sign 參數」+ 模擬 APP 端請求

京東 PC 端反爬極嚴（頻繁觸發滑塊驗證碼），但 APP 端接口（通過 Charles 抓包獲取）的參數邏輯更固定，適合大規模數據爬取：

• 核心步驟：破解 sign 參數加密

① 抓包分析：用「夜神模擬器 + Charles」抓取京東 APP 的商品列表接口（如「https://api.m.jd.com/api?functionId=search&...」），發現sign參數是關鍵；

② 逆向 JS：在 APP 安裝目錄中找到「jdmall.js」（或通過 FridaHook Hook 加密函數），拆解出sign的生成邏輯：sign = md5(secretKey + 拼接參數（functionId+timestamp+appid+參數） + secretKey)，其中「secretKey」是固定值（不同 APP 版本可能變化，需定期更新）；

③ 設備指紋模擬：APP 端接口需攜帶「deviceId」「uuid」「imei」，用 Python 的faker庫生成符合京東格式的假設備信息（避免用固定值，否則會被識別為爬蟲設備）。

• 實戰技巧：庫存數據爬取

京東商品庫存接口（「https://c0.3.cn/stock」）需攜帶「skuId+area（地區編碼，如北京是 1_0_0）」，且同一 IP 下請求不同地區庫存，需間隔 30 秒以上，否則會被判定為「地域跳轉異常」。

3. 拼多多：只能「APP 端模擬 + 設備指紋繞過」

拼多多是三大平臺中反爬最嚴的，PC 端幾乎無法爬取有效數據，必須聚焦 APP 端：

• 核心步驟：突破 anti_content 參數

① 設備環境模擬：用「雷電模擬器 + Xposed 框架」安裝拼多多 APP，通過「JustTrustMe」繞過 SSL 證書驗證，再用「Frida」Hook 生成anti_content的函數（anti_content是基于設備指紋 + 請求參數的加密字符串，無法直接逆向）；

② 低頻率請求：拼多多對「設備 + IP」的綁定關系極敏感，同一設備 + IP 每天爬取商品數不能超過 50 個，否則會觸發「賬號凍結」（即使是未登錄狀態）；

③ 數據取舍：拼多多的「商品評價」接口做了「內容混淆」（如評價內容中插入特殊字符），爬取后需用正則清洗（如re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9]', '', content)），且僅能獲取前 20 頁評價（后續頁面會返回空數據）。

三、爬蟲工程師必看：3 個關鍵避坑點（比技術更重要）

1. IP 池：別用免費代理，低成本選「動態撥號 + 隧道代理」

• • 免費代理：90% 以上是「高風險 IP」（已被平臺標記），用一次就會導致整個 cookie 池失效；

• • 推薦方案：中小規模（日爬 1 萬條數據）用「動態撥號 IP（如芝麻代理）」，每個 IP 綁定 1 個 cookie，請求間隔設置 5-10 秒；大規模（日爬 10 萬 +）用「隧道代理（如阿布云）」，自動切換 IP，避免手動維護。

1. 數據合規：3 條紅線絕對不能碰

• • 不爬「隱私數據」：用戶手機號、收貨地址、支付信息（即使能獲取到，也屬于違法，《個人信息保護法》明確禁止）；

• • 不商用「爬取數據」：若將數據用于商業分析，需先查看平臺「robots 協議」（淘寶 robots 禁止爬取商品詳情頁，京東允許非商用爬取），且最好與平臺溝通獲取授權（如京東開放平臺有官方 API，比爬蟲更穩定）；

• • 不破壞平臺規則：如不用爬蟲搶購商品、刷評價，否則會被追究法律責任（2023 年有案例：某公司用爬蟲刷拼多多銷量，被判賠償 200 萬元）。

1. 監控與容錯：避免「爬了半天全是無效數據」

• • 數據校驗：爬取后立即校驗「價格是否為數字」「庫存是否合理（如 > 10000 可能是異常值）」，發現異常則切換 IP+cookie；

• • 失敗重試：用「指數退避算法」（如第 1 次失敗等 1 秒，第 2 次等 2 秒，第 3 次等 4 秒）替代固定重試間隔，避免加重服務器負擔；

• • 日志記錄：每一條請求都記錄「IP+cookie + 請求參數 + 返回狀態碼」，出問題時能快速定位是「IP 被封」還是「參數失效」。

四、總結：電商爬蟲的核心不是「技術多牛」，而是「平衡」

做淘寶、京東、拼多多的商品爬蟲，從來不是「破解所有反爬」，而是在「爬取效率」「數據質量」「合規安全」之間找平衡：

• 小需求（如個人分析某品類價格）：用 Playwright 模擬 PC 端，低頻率爬取，無需復雜逆向；

• 中需求（如企業監測競品價格）：對接平臺官方 API（如淘寶開放平臺「item_get」接口），雖然有調用次數限制，但穩定合規；

• 大需求（如全品類數據爬取）：組建「IP 池 + cookie 池 + 設備池」，配合行為模擬，且定期更新反爬策略（平臺每 3-6 個月會調整一次參數加密規則）。

最后提醒：爬蟲技術是工具，別為了「爬數據」而忽視合規 —— 現在電商平臺都有專門的反爬團隊，一旦被判定為「惡意爬蟲」，不僅會封 IP 賬號，還可能面臨法律風險，得不償失。