电商比价爬虫：同时爬取某东+某宝+某猫，实现全网比价

傻啦嘿哟

741人浏览 · 2026-09-04 14:06:42

傻啦嘿哟 · 2026-09-04 14:06:42 发布

引言

“想监控竞品价格，结果刚跑了10分钟，IP就被封了……”“双11大促想跟踪价格波动，每5分钟就要刷新一次页面，可刷着刷着就弹出了滑块验证，采着采着就报403……”

如果你正在做电商运营、市场分析或选品决策，这些场景一定不陌生。跨平台比价听起来简单——把同一商品在某东、某宝、某猫三个平台的价格都抓下来，排个序——但做起来全是坑：某东需要Cookie和登录态，某宝需要逆向sign签名，某猫的“星盾”系统更是动态令牌、IP画像、JS加密三重防护叠加。

本文将从技术原理出发，系统介绍如何搭建一套同时覆盖某东、某宝、某猫的电商比价爬虫系统。文章将剖析三大平台的反爬差异，提供可落地的技术架构与代码实现，并重点讲解站大爷隧道代理在跨平台比价场景中的关键作用。

免责声明：本文仅限技术学习与交流，请勿将爬虫技术用于商业用途或对目标网站造成过大压力。请遵守各平台的robots.txt协议及相关法律法规。

一、三大平台反爬体系对比

在动手写代码之前，必须先搞清楚三个平台分别“防什么”——它们的反爬策略完全不同，一套代码通吃三个平台几乎不可能。

1.1 某宝：六层防御，加密最复杂

某宝的反爬系统经过近20年迭代，已经从单一的请求头校验升级为 “全维度感知+实时风险评估+动态拦截” 的企业级防御体系。阿里宙斯系统每天处理超过100亿次请求，对自动化脚本的识别准确率高达98%以上。

某宝的反爬体系分为六个层级，层层递进：

层级	技术手段	检测对象
L1：请求特征	UA缺失、无Referer、无Cookie	请求头完整性
L2：频率控制	IP/账号QPS过高	请求频率
L3：环境指纹	WebDriver特征、Canvas指纹	浏览器环境
L4：行为轨迹	鼠标轨迹、点击间隔、页面停留	操作模式
L5：参数加密	`_m_h5_tk`、`sign`动态参数	请求合法性
L6：数据混淆	字体反爬、JSON乱序	数据解析

其中L5是最大的技术门槛。某宝的商品列表、详情等接口均为异步AJAX请求，请求参数中包含多个加密字段（如_m_h5_tk、_m_h5_tk_enc、sign），直接构造请求会返回403/500错误。sign参数依赖Cookie中的_m_h5_tk，且与请求时间戳绑定，需要完整的JS逆向才能复现。

1.2 某猫：“星盾”系统，动态令牌+IP画像

某猫作为国内最大的B2C平台，其反爬体系已演进至第五代系统。核心特征包括：

动态令牌与设备指纹：每个请求需携带包含时间戳、设备指纹、行为轨迹的动态令牌头部。Web端还会采集Canvas指纹、WebGL渲染器、字体列表等环境特征。

IP行为画像：基于请求间隔、URL访问序列、页面停留时间等维度建立机器学习模型，实时评估每个IP的可疑程度。单纯用同一个IP高频请求，几乎必被封。

动态渲染与价格加密：许多商品价格是在页面渲染后才动态加载的，基础HTTP请求只能拿到不完整的页面。某猫还会通过JavaScript加密关键价格数据，直接抓HTML拿不到真实价格。

1.3 某东：相对友好，但Cookie是“命门”

相比某宝和某猫，某东的反爬相对友好一些，但也有自己的特点。

核心依赖Cookie：某东商品详情页的核心数据虽然首屏静态渲染，但实时价格等敏感信息需携带登录态Cookie才能获取。没有Cookie，返回的数据往往是空的。

频率限制：实测表明，同一IP连续请求超过10次/分钟就会触发临时封禁。这个限制是动态的——夜间阈值比白天宽松约30%，但大促期间反而更严。

无需登录的例外：部分开源项目发现，某东的某些接口在特定条件下可以不依赖登录态采集。

1.4 三大平台反爬对比速览

维度	某宝	某猫	某东
加密复杂度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐
Cookie依赖	强（7-15天过期）	强（7-15天过期）	中
IP封禁严厉度	极严	极严	较严
签名参数	sign、_m_h5_tk	动态令牌	部分接口需要
JS逆向难度	极高	高	低

二、技术架构设计

面对三个平台差异巨大的反爬策略，一套“大一统”的爬虫代码是不现实的。正确的做法是分层架构 + 平台适配器。

2.1 整体架构

┌─────────────────────────────────────────────────────────────┐
│                      调度层（Celery/Airflow）               │
│                   定时触发、任务队列、重试策略               │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                    平台适配层（Adapter Pattern）            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                 │
│  │ 某宝适配器 │  │ 某猫适配器 │  │ 某东适配器 │                 │
│  │sign逆向+  │  │动态令牌+  │  │Cookie+   │                 │
│  │Cookie池   │  │设备指纹   │  │接口直调  │                 │
│  └──────────┘  └──────────┘  └──────────┘                 │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                   代理层（站大爷隧道代理）                   │
│              自动IP轮换、地域选择、故障自愈                  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                   数据层（清洗 + 存储）                      │
│         数据标准化、去重、SQLite/MySQL时序存储               │
└─────────────────────────────────────────────────────────────┘

这种架构的核心优势在于：各平台的采集逻辑相互隔离，修改一个不影响另一个；代理层统一管理IP，所有平台的请求共享同一个隧道代理出口。

2.2 核心难点：数据标准化

三个平台返回的数据结构完全不同——某东用price字段，某宝用zk_final_price，某猫的价格藏在加密的JSON里。比价系统的关键在于将不同平台的数据映射到统一的数据模型：

# 统一数据模型
standard_product = {
    "platform": "taobao" | "tmall" | "jd",
    "product_id": "平台商品ID",
    "title": "商品标题",
    "price": 99.99,          # 统一为浮点数
    "original_price": 129.99, # 划线价
    "currency": "CNY",
    "sales": 10086,          # 月销量
    "rating": 4.9,           # 评分
    "sku_info": {...},       # SKU信息
    "collected_at": "2026-09-04 10:00:00"
}

跨平台比价的核心不是“爬”，而是“对齐”——同一个商品在不同平台的ID不同、标题写法不同、规格描述不同，需要通过SKU编码或商品条码进行关联。

三、各平台采集方案详解

3.1 某宝采集：Cookie池 + sign签名逆向

某宝的采集是三个平台中技术门槛最高的。核心步骤包括：

第一步：获取Cookie与_m_h5_tk

通过浏览器登录某宝，在开发者工具的Application中复制完整的Cookie字符串。从Cookie中提取_m_h5_tk字段（取“_”之前的部分作为token）。

第二步：逆向sign签名算法

某宝的sign参数生成逻辑为：

sign = MD5(token + "&" + timestamp + "&" + appKey + "&" + data)

其中token来自_m_h5_tk，timestamp是13位毫秒级时间戳，appKey是固定的应用标识（通常为12574478），data是请求参数的JSON字符串。

import hashlib
import json
import time

def generate_taobao_sign(token, timestamp, app_key, data):
    sign_str = f"{token}&{timestamp}&{app_key}&{json.dumps(data)}"
    return hashlib.md5(sign_str.encode()).hexdigest()

第三步：Cookie池管理

某宝的Cookie默认有效期7-15天。比价系统需要维护一个Cookie池，定期刷新失效的Cookie，确保采集任务不会因为Cookie过期而中断。

第四步：移动端接口优先

经过对比测试，https://m.tmall.com或https://h5.m.taobao.com等移动端H5页面的接口，其参数加密逻辑通常比PC端简单。优先使用移动端接口可以降低逆向难度。

3.2 某猫采集：动态令牌 + 设备指纹

某猫的采集难度仅次于某宝。其核心是动态令牌的生成。

第一步：获取设备指纹

某猫的Web端会采集Canvas指纹、WebGL渲染器、字体列表等环境特征。这些特征需要在使用Playwright或Selenium时通过真实浏览器获取，无法用requests模拟。

第二步：构造动态令牌

每个请求需携带包含时间戳、设备指纹、行为轨迹的动态令牌头部。令牌的生成逻辑需要从页面JS中逆向提取，或通过浏览器自动化工具让浏览器自动生成。

第三步：处理价格加密

某猫会通过JavaScript加密关键价格数据。这意味着不能简单地解析HTML，而需要等待JS执行完成后提取渲染后的价格，或者直接调用价格接口。

3.3 某东采集：Cookie + 接口直调

某东是三个平台中最容易采集的。

第一步：获取Cookie

用Chrome浏览器打开某东商品页并登录，按F12打开开发者工具→点“Network”→刷新页面，找任意一个API请求→在“Headers”里复制Cookie字段值。

第二步：调用价格接口

某东的价格通过异步接口加载。通过抓包分析，价格接口的URL规律为：

https://p.3.cn/prices/mgets?skuIds=J_{product_id}

返回JSON格式的价格数据，直接解析即可。

第三步：处理登录态

部分敏感信息（如实时价格）需携带登录态Cookie。建议使用requests.Session()自动管理Cookie，或定期从浏览器刷新Cookie。

3.4 采集频率控制

价格监控场景天然具备高频、批量、规律性的特征。为了避免触发各平台的风控，需要精细控制采集频率：

平台	建议请求间隔	单次并发数
某宝	3-5秒	1-2
某猫	3-5秒	1-2
某东	1-2秒	3-5

所有请求之间应加入随机延迟（random.uniform(min, max)），而非固定间隔，避免被行为模式检测识别。

四、站大爷隧道代理：跨平台比价的“基础设施”

4.1 为什么比价爬虫离不开代理？

2026年主流电商平台（某宝、某东等）反爬体系全面升级，不再局限于基础IP封禁，新增了TLS指纹校验、请求行为轨迹检测、同城IP集群风控、Cookie链路追踪四重防护机制。

跨平台比价爬虫面临的IP困境尤为突出：

IP封禁率居高不下：高频批量采集商品价格时，原生公网IP秒级封禁，普通数据中心代理存活时长不足5分钟
地域数据采集受限：电商平台实行分区域定价策略，单一地区IP无法获取全国各省市真实商品售价
运维成本过高：自研代理池维护难度大，IP清洗、去重、失效检测需要专人运维

4.2 隧道代理 vs 传统代理池

传统代理池需要手动收集、验证、维护IP列表，而隧道代理只需要一个固定入口，后台自动按照设定的频率切换出口IP。

以站大爷隧道代理为例，实测数据非常亮眼：

指标	站大爷实测值	行业平均水平
24小时连接成功率	99.3%	90%-95%
IP初始可用率	98.6%	80%-90%
强反爬采集成功率	98%	约70%
平均响应速度	88-189ms	200-350ms
故障自愈速度	<30秒	3-5分钟
全国城市覆盖	300座+	200座以内

有一家国内中型电商零售企业需要7×24小时不间断采集全平台竞品商品数据，用于动态调价、库存预警、市场行情分析。项目最终接入站大爷隧道代理+短效优质代理双模式方案，重构分布式爬虫网络层架构，彻底解决了反爬封禁问题。改造前免费代理池日均可用率仅42%，单日采集成功率仅61%；改造后成功率提升至98%以上。

4.3 在比价爬虫中集成站大爷隧道代理

站大爷隧道代理的入口格式为http://用户名:密码@tps.zdaye.com:8080。在requests中集成非常简单：

import requests
from fake_useragent import UserAgent

# 站大爷隧道代理配置
PROXY_CONFIG = {
    "http": "http://用户名:密码@tps.zdaye.com:8080",
    "https": "http://用户名:密码@tps.zdaye.com:8080"
}

ua = UserAgent()

def fetch_with_tunnel(url, headers=None, retry=3):
    """统一请求函数：自动使用隧道代理，支持重试"""
    if headers is None:
        headers = {"User-Agent": ua.random}
    
    for attempt in range(retry):
        try:
            response = requests.get(
                url,
                headers=headers,
                proxies=PROXY_CONFIG,
                timeout=15
            )
            if response.status_code == 200:
                return response
            if response.status_code in [403, 429]:
                print(f"第{attempt+1}次请求被拒绝，隧道代理自动切换IP重试...")
                time.sleep(3 * (attempt + 1))
        except Exception as e:
            print(f"请求异常: {e}")
            time.sleep(3)
    return None

对于需要精细控制IP轮换的场景，站大爷隧道代理支持通过period参数自定义IP更换频率：

# 每300秒更换一次IP
PROXY_CONFIG = {
    "http": "http://用户名-period-300:密码@tps.zdaye.com:8080",
    "https": "http://用户名-period-300:密码@tps.zdaye.com:8080"
}

在跨平台比价场景中，建议每个平台的请求使用不同的IP出口，避免平台之间通过IP关联识别爬虫行为。

五、比价系统的完整实现

5.1 统一采集框架

以下是一个简化的多平台比价采集框架：

import time
import random
import json
import hashlib
import requests
from abc import ABC, abstractmethod
from fake_useragent import UserAgent

class PlatformAdapter(ABC):
    """平台适配器基类"""
    
    def __init__(self, proxy_config):
        self.proxy_config = proxy_config
        self.ua = UserAgent()
        self.session = requests.Session()
    
    @abstractmethod
    def search(self, keyword, page=1):
        """搜索商品"""
        pass
    
    @abstractmethod
    def get_detail(self, product_id):
        """获取商品详情"""
        pass
    
    def _request(self, url, params=None, headers=None, retry=3):
        """统一请求方法，使用隧道代理"""
        if headers is None:
            headers = {"User-Agent": self.ua.random}
        
        for attempt in range(retry):
            try:
                resp = self.session.get(
                    url,
                    params=params,
                    headers=headers,
                    proxies=self.proxy_config,
                    timeout=15
                )
                if resp.status_code == 200:
                    return resp
                if resp.status_code in [403, 429]:
                    time.sleep(3 * (attempt + 1))
            except Exception as e:
                time.sleep(3)
        return None


class TaobaoAdapter(PlatformAdapter):
    """某宝适配器"""
    
    def __init__(self, cookie, proxy_config):
        super().__init__(proxy_config)
        self.cookie = cookie
        self.app_key = "12574478"
        self._token = self._extract_token(cookie)
    
    def _extract_token(self, cookie):
        """从Cookie中提取_m_h5_tk的token部分"""
        import re
        match = re.search(r'_m_h5_tk=([^;]+)', cookie)
        return match.group(1).split('_')[0] if match else ""
    
    def _generate_sign(self, timestamp, data):
        """生成sign签名"""
        sign_str = f"{self._token}&{timestamp}&{self.app_key}&{json.dumps(data)}"
        return hashlib.md5(sign_str.encode()).hexdigest()
    
    def search(self, keyword, page=1):
        """搜索某宝商品（移动端接口）"""
        url = "https://h5.m.taobao.com/..."
        timestamp = str(int(time.time() * 1000))
        data = {"q": keyword, "page": page}
        sign = self._generate_sign(timestamp, data)
        
        headers = {
            "User-Agent": self.ua.random,
            "Cookie": self.cookie,
            "x-sign": sign,
            "x-t": timestamp
        }
        # 发送请求...
        return self._request(url, params=data, headers=headers)


class JDAdapter(PlatformAdapter):
    """某东适配器"""
    
    def __init__(self, cookie, proxy_config):
        super().__init__(proxy_config)
        self.cookie = cookie
    
    def get_price(self, product_id):
        """获取某东商品价格"""
        url = f"https://p.3.cn/prices/mgets?skuIds=J_{product_id}"
        headers = {
            "User-Agent": self.ua.random,
            "Cookie": self.cookie,
            "Referer": "https://item.jd.com/"
        }
        resp = self._request(url, headers=headers)
        if resp and resp.status_code == 200:
            data = resp.json()
            return {"price": data[0].get("p"), "product_id": product_id}
        return None


class PriceMonitor:
    """比价监控系统"""
    
    def __init__(self, proxy_config):
        self.proxy_config = proxy_config
        self.adapters = {}
    
    def register_adapter(self, name, adapter):
        self.adapters[name] = adapter
    
    def compare(self, product_ids):
        """跨平台比价"""
        results = {}
        for platform, adapter in self.adapters.items():
            pid = product_ids.get(platform)
            if pid:
                result = adapter.get_detail(pid)
                if result:
                    results[platform] = {
                        "price": result.get("price"),
                        "title": result.get("title")
                    }
            time.sleep(random.uniform(1, 3))  # 平台间间隔
        return results


# 使用示例
if __name__ == "__main__":
    PROXY_CONFIG = {
        "http": "http://用户名:密码@tps.zdaye.com:8080",
        "https": "http://用户名:密码@tps.zdaye.com:8080"
    }
    
    monitor = PriceMonitor(PROXY_CONFIG)
    
    # 注册各平台适配器
    monitor.register_adapter("taobao", TaobaoAdapter("你的Cookie", PROXY_CONFIG))
    monitor.register_adapter("jd", JDAdapter("你的Cookie", PROXY_CONFIG))
    
    # 跨平台比价
    product_ids = {"taobao": "610947572360", "jd": "100043467842"}
    result = monitor.compare(product_ids)
    print("比价结果：", result)

5.2 定时采集与价格趋势

比价系统的核心价值在于持续监控而非单次查询。建议使用Celery Beat或APScheduler设置定时任务：

from apscheduler.schedulers.background import BackgroundScheduler

def daily_price_task():
    """每日定时比价任务"""
    monitor = PriceMonitor(PROXY_CONFIG)
    # 采集所有监控商品...
    # 存储到数据库...
    # 触发价格变动告警...

scheduler = BackgroundScheduler()
scheduler.add_job(daily_price_task, 'interval', hours=1)
scheduler.start()

每次采集的价格快照存入SQLite或MySQL，积累一定数据后即可生成价格趋势图表，识别“先涨后降”的促销套路。

六、常见问题与避坑指南

6.1 某宝sign签名无法生成怎么办？

确认Cookie中的_m_h5_tk是否有效（Cookie过期会导致签名无效）
检查时间戳是否为13位毫秒级
确认appKey是否正确（不同接口可能使用不同的appKey）
考虑使用curl_cffi库模拟Chrome TLS指纹

6.2 某猫动态令牌失效怎么办？

动态令牌与设备指纹强绑定，建议使用Playwright获取完整的浏览器上下文
定期刷新令牌，某猫的令牌有效期通常为数小时
避免在多IP之间共享同一个令牌

6.3 某东Cookie频繁过期怎么办？

某东Cookie默认有效期7-15天
建立Cookie池，定期从浏览器自动刷新
部分接口可以不依赖登录态，优先使用这些接口

6.4 三个平台数据无法对齐怎么办？

通过商品条码（EAN/UPC）进行跨平台关联
通过标题+品牌+规格的模糊匹配算法
建立商品映射表，人工或半自动维护关联关系

6.5 IP被封后如何快速恢复？

使用站大爷隧道代理的自动故障自愈功能（<30秒恢复）
配置period参数控制IP更换周期
不同平台使用不同的IP出口，避免关联封禁

七、总结

跨平台电商比价爬虫的难点不在于“爬”，而在于“同时爬”——三个平台的反爬策略差异巨大，需要分别适配；IP封禁问题在跨平台场景下更加突出；数据标准化需要建立统一的映射规则。

本文的核心方案可以概括为：

挑战	解决方案
某宝sign签名加密	Cookie池 + 移动端接口 + sign逆向
某猫动态令牌+设备指纹	Playwright获取指纹 + 令牌定期刷新
某东Cookie依赖	Session管理 + Cookie池
跨平台IP封禁	站大爷隧道代理，自动切换IP
多平台数据对齐	统一数据模型 + SKU映射
持续监控	定时任务 + 时序存储 + 趋势分析