大规模电商数据抓取

抓取一个商品页面是教程级别的任务。每天抓取几百万个商品页面而不让管道陷入停滞，则是一个系统工程问题。大规模电商数据抓取是价格监控、目录和品类跟踪、竞争对手基准测试以及需求信号挖掘的基础，这类分析需要覆盖完整货架，而非仅仅采样。从数百页面扩展到数百万页面，不仅仅是增加工作量，而是改变了可能出问题的环节以及你必须采用的架构。

本指南聚焦于公开数据：任何人无需登录即可查看的商品列表、价格、库存状态、评分和评价数量。不涉及用户账户、购物车、订单或个人数据。我们将深入探讨团队为何要这样做、仅在大规模时才会出现的挑战，以及一套能够经受考验的架构，其中 Crawlbase Crawling API、异步 Crawler 和 Smart AI Proxy 将被定位为规模扩展层。

为什么要大规模抓取电商数据

单个商品页面告诉你某一个价格的当前状态。大规模的价值在于广度和历史：跨多家零售商追踪数千个 SKU，采样频率足以观测到价格变动。这才是将原始商品列表转化为决策依据的关键。以下四个用例驱动了大多数大规模电商抓取工作。

• 价格监控。跨目录长期追踪竞争对手价格，以便及时调价、发现促销活动，并在降价发生当天而非一周后察觉到。
• 目录和品类跟踪。梳理零售商的在售品类、库存状态及商品描述，以便发现自身品类的空缺，并观察竞争对手向新品类扩展的动向。
• 竞争对手基准测试。在同一 SKU 上将你的价格、评分和评价增速与竞争对手进行比较，以了解你在哪里占优、在哪里正在失去购物车。
• 需求信号。评价数量、评分趋势和库存流转是销售情况的公开代理指标。跨多家门店持续观测，能够在爆款商品出现在你自己的销售数据之前提前发现。

这与任何电商网页抓取任务的形态相同。大规模的差异纯粹在于体量，而体量恰恰是简单方案崩溃的地方。

从数百页面扩展到数百万页面时，什么会发生变化

一个在笔记本电脑上抓取几百个页面的脚本，无法承受被指向数百万个页面时的压力。以下问题在小体量时表现轻微，在大规模时却成为工作的全部。

体量与并发

逐页串行抓取适合演示，对于完整目录而言毫无希望。数百万页面意味着需要同时维持大量请求，这要求请求调度、背压控制，以及在某个工作节点中途崩溃时不丢失任务的机制。从单进程同步运行，是第一个会崩溃的环节。

反爬防护

大型零售商运行着复杂的爬虫检测系统。数据中心 IP、重复的请求模式和缺失的浏览器指纹会触发 CAPTCHA 验证或直接被屏蔽。你抓取的页面越多，从某个来源产生的流量就越大，触发这些防护机制的速度也就越快。对一百次请求有效的方法，在十万次请求时会让你被封禁。

IP 轮换

应对封锁的方法是将请求分散到多个 IP，使任何单一地址都不会显得过于异常。在小规模时，少量代理已经足够。在大规模时，你需要一个深度住宅代理池和一套轮换策略，使任何单一 IP 的请求量都保持在速率限制以下，这是需要构建和持续维护的真实基础设施。

数据新鲜度

价格数据只有在实时的情况下才有价值。一次完整目录爬取耗时三天，给你的是三天前的价格，这对于重新定价来说毫无意义。新鲜度要求你快速且按计划爬取，这进一步提升了并发压力和反爬压力。

数据质量

在大体量下，少量畸形页面、布局变体和部分加载会变成数以千计的问题行。不同零售商的页面结构各不相同，且会在没有通知的情况下发生变化，因此假定某种布局的提取逻辑会静默地返回空字段。如果没有校验和监控，你将不会察觉到问题，直到错误数据已经进入报告。

能够应对规模的架构

一个能够处理数百万页面的管道由四个阶段组成，每个阶段都可以独立扩展：发现 URL、抓取页面、解析为结构化行，以及带校验的存储。将它们视为一个单体脚本，正是让小型爬虫无法成长的原因。

• URL 发现。遍历分类页和搜索结果页，构建所需商品 URL 的列表。这本身就是一次爬取，也是所有下游环节的输入。
• 抓取。在轮换 IP 后拉取每个 URL，在页面需要时进行渲染，失败时重试，并保持足够的并发以达到新鲜度目标。
• 解析。将 HTML 转化为干净的行：名称、价格、货币、库存状态、评分、评价数量。可以使用自定义选择器，也可以使用自动解析。
• 存储与校验。将数据行写入可查询的存储，在写入时进行校验，并对异常进行标记，以便质量问题能够立即浮现。

抓取阶段是大部分难点所在，也是 Crawlbase 被设计来承接的阶段。与其自己运行无头浏览器集群和代理池，不如调用 Crawling API，让它在服务端处理渲染、轮换和解封。

使用 Crawling API 进行单次抓取

以下是对一个公开分类页面进行同步抓取并随后解析的示例。Crawling API 接收你的令牌和目标 URL，通过可信 IP 路由请求，并将 HTML 返回给你进行提取。

const { CrawlingAPI } = require('crawlbase')
const cheerio = require('cheerio')

const api = new CrawlingAPI({ token: 'YOUR_CRAWLBASE_TOKEN' })

const categoryURL = 'https://example-store.com/c/laptops?page=1'

async function scrapeCategory(url) {
  const response = await api.get(url, { ajax_wait: true, page_wait: 3000 })
  const $ = cheerio.load(response.body)
  const products = []

  $('.product-card').each((i, el) => {
    products.push({
      name: $(el).find('.product-title').text().trim(),
      price: $(el).find('.price').text().trim(),
      inStock: $(el).find('.availability').text().trim(),
      rating: $(el).find('.rating').attr('data-value'),
    })
  })

  return products
}

scrapeCategory(categoryURL).then((rows) => console.log(rows))

这两个选项对现代电商网站至关重要。ajax_wait 告知 API 等待异步内容加载完成，page_wait 则等待固定毫秒数，以确保延迟渲染的价格在 HTML 返回之前已经出现。选择器只是占位符：在开发者工具中检查你的目标网站，并将每个字段映射到真实的选择器。

使用 Scraper API 跳过选择器

为每家零售商编写和维护选择器本身就是一种负担。Crawlbase Crawling API 可以直接为受支持的电商页面返回结构化 JSON，让你无需自行解析 HTML 即可获得名称、价格、库存状态和评分字段。在大规模时，自定义解析器越少，意味着在网站更新标记时静默失败的环节也越少。

使用 Crawler 实现异步化

同步调用适用于数千个页面。对于数百万个页面，阻塞等待每次请求并手动管理重试是无法扩展的。异步 Crawler 翻转了这一模式：你将 URL 推送给它，它在后台进行爬取，并为你处理轮换和重试，然后在完成时将每个结果推送到你控制的 webhook。你的代码不再等待响应，只需接收已解析好的页面。

const { CrawlingAPI } = require('crawlbase')

const api = new CrawlingAPI({ token: 'YOUR_CRAWLBASE_TOKEN' })

const urls = [
  'https://example-store.com/p/sku-1001',
  'https://example-store.com/p/sku-1002',
  'https://example-store.com/p/sku-1003',
]

async function queueAll(list) {
  for (const url of list) {
    await api.post(url, { callback: 'https://your-app.com/webhook' })
  }
}

queueAll(urls).then(() => console.log('Queued', urls.length, 'URLs'))

这正是适配新鲜度计划的模式：将完整的 URL 列表入队，让 Crawler 并发处理，并在结果到达时逐条处理。失败的页面在服务内部进行重试，因此你的 webhook 处理器只需处理已完成的任务。这就是脚本与管道之间的本质区别。

当你只需要代理层而非解析器时

有些团队已有成熟的抓取技术栈，只需要解封层。Crawlbase Smart AI Proxy 是一个单一端点，位于你现有 HTTP 客户端或无头浏览器的前端，通过轮换住宅代理池路由流量，让你保留现有代码的同时获得轮换能力。如果你想了解轮换在底层的工作机制，轮换住宅代理涵盖了相关原理。

在大体量下保持高数据质量

大规模下的干净数据是一个流程问题，而非解析器问题。以下几个习惯能让大型爬取任务保持可信。

• 写入时校验。拒绝或标记价格缺失、货币无法解析或名称为空的行，防止问题页面污染数据集。
• 跟踪提取率。如果产出完整记录的页面比例下降，网站可能更新了标记。主动设置告警，而不是在报告中被动发现。
• 让管道具备幂等性。以 URL 加时间戳作为行的主键，防止重试和重跑产生重复计数，这一点在引入重试机制后尤为重要。
• 抽样和人工核查。定期从实时页面抽取少量行进行比对，确认价格和库存状态与实际情况一致。

坦诚的部分：服务条款和 robots

大规模抓取大型商业零售商处于法律灰色地带，是否被允许取决于平台的服务条款、你的司法管辖区以及你对数据的用途。许多零售商在其条款中限制自动化访问，因此无论你的工具多么谨慎，抓取行为都可能违反这些条款。此处的工具无法改变这一点，它们只是让技术层面的工作得以实现。

有几条准则值得坚守。只采集公开数据：任何人无需账户即可查看的商品列表、价格、库存状态和评分。遵守每个网站的 robots.txt 和其明示的速率预期，将请求量控制在不会给任何人服务器造成负担的水平。绝不采集个人数据、与个人用户账户关联的任何信息，或任何登录后才能访问的内容。如果你计划将数据用于商业用途，请获得许可或签订正式数据协议，而不是默认沉默即同意。更完整的操作规范请参阅如何在不被封锁的情况下抓取网站。

常见问题

什么算是大规模电商抓取？

没有明确的分界线，但这个词通常指在单个脚本加几个代理就无法正常运行的体量下爬取商品目录：从数万页面到数百万页面，定期刷新。在这个体量下，工作重心从编写选择器转移到运行可靠的基础设施，并发、IP 轮换、重试和数据校验承担了大部分繁重工作。

抓取数百万商品页面时如何避免被封锁？

将请求分散到大量轮换住宅 IP，使任何单一地址都不会触发速率限制；将每个 IP 的速率保持在低水平；在网站需要 JavaScript 时进行渲染。Crawling API 和 Smart AI Proxy 在服务端处理轮换和解封；如果你自己搭建技术栈，那就是需要重点投入的部分。监控状态码，一旦出现挑战就立即退避。

应该使用同步 Crawling API 还是异步 Crawler？

对于交互式或较小规模的任务（需要立即获得响应），使用同步 Crawling API。对于大批量任务，使用异步 Crawler：你推送 URL，它在后台进行爬取，为你处理轮换和重试，并将每个完成的结果推送到你的 webhook。对于需要按新鲜度计划处理数百万页面的场景，异步模型能防止你的代码阻塞在每次请求上。

如何保持抓取价格数据的新鲜度？

按照你的使用场景所需的频率定期爬取，对于重新定价通常意味着每天甚至更频繁。新鲜度推高了并发压力和反爬压力，因此能处理轮换和重试的服务可以让你在时间窗口内完成整个目录的爬取。将完整的 URL 列表入队到异步 Crawler，并在结果到达时逐条处理，而不是等待串行运行完成。

我需要为每家零售商编写解析器吗？

不一定。Scraper API 可以为受支持的电商页面返回结构化 JSON，让你无需编写选择器就能获得名称、价格、库存状态和评分字段。对于不支持的网站，使用 Crawling API 获取 HTML，然后用 Cheerio 等库进行解析。自定义解析器越少，意味着在网站更新标记时静默失败的环节也越少。

大规模抓取电商网站合法吗？

这取决于网站的服务条款、你的司法管辖区和你的目的，许多零售商限制自动化访问。严格限于公开的商品列表数据，遵守 robots.txt 和速率预期，绝不触碰账户、个人数据或需要登录才能执行的操作。对于商业用途，获得许可或签订正式数据协议，而不是依赖爬虫。

FA

Farwa Anees

技术撰稿人 · Crawlbase

技术撰稿人，在 Crawlbase 博客上撰写代理、网页抓取与数据基础设施，把繁杂的网络主题转化为工程师真正能读完的指南。