亚马逊API 与网页抓取对比:亚马逊 API 与网页抓取不是二选一。官方 SP-API 只覆盖你自己的账户数据，公开页面采集覆盖竞品与市场事实——两者回答的根本不是同一个问题。多数成熟的生产系统两条路都走。本文给出授权边界、公开与私有数据的分界、同口径成本比较、可落地的混合架构，以及一张按任务对号入座的决策表。
「该用官方 API 还是直接抓？」这个问题之所以让人反复纠结，是因为它被问错了。它预设两者是同一件事的两种实现，于是比较就变成了谁更合规、谁更便宜、谁更稳定。但真相是：它们获取的是两类不同的数据。官方接口给你的是你的账户，公开页面给你的是整个市场。想清楚这一点，路线之争就消失了，剩下的是一个架构分工问题。若你需要更上层的选型框架，可先读 亚马逊数据 API：商业调研与方案选型完整指南。
一、为什么”二选一”是错误框架
市面上几乎所有同类对比文章，都把官方 API 和网页抓取摆成擂台的两边，然后给出一张优劣表。这个结构好读，但它误导了决策。
关键在于两者的数据域几乎不重叠。官方 SP-API 的授权范围严格绑定在你的卖家账户上——订单、库存、履约、自家 listing、自家广告表现。它回答的是”我的生意现在怎么样”。而公开页面采集能拿到的是商品信息、搜索结果、评论、榜单排名、广告位——它回答的是”市场现在怎么样”。
这是两个问题。你不会因为”官方 API 更合规”就用它去查竞品价格，因为它在设计上就不提供这些数据；也不会因为”抓取覆盖更广”就用它去拉自己的订单，因为订单在登录之后，且属于账户私有数据。
所以正确的问法不是”选哪个”，而是”我的哪些问题属于账户域，哪些属于市场域”。前者走官方接口，后者走公开数据。绝大多数团队的答案是两个都有。
二、授权边界：两条路线的合法性来自哪里
合规讨论最容易滑向「哪个更合法」这种无解的比较。实际上两条路线的合规来源完全不同，取决于你采什么，而不是用什么方法。
官方 SP-API：协议授权
SP-API 的合法性来自一整套显式协议：开发者注册、卖家通过 Login with Amazon 授权、应用通过角色（role）获得最小必要权限。涉及个人身份信息（PII）的操作需要单独申请受限角色并通过审核。违反的是开发者协议与数据保护政策，后果是授权被撤销。
它的边界很清晰，但也很窄：只有卖家主动授权给应用的那部分数据。你拿不到其他卖家的订单，也拿不到市场级的排名数据。
公开页面采集：条款与 robots 约束
采集公开页面不由协议授权，而是落在平台使用条款、robots 指令与速率限制的约束下。没有一纸合同，但也不等于禁止——公开可见、非个人的页面信息原则上可以采集，这是行业长期实践。
风险随三件事上升，这三件事才是真正需要警惕的：
- 登录可见内容：登录后才能看到的页面明显越过了”公开”这条线。
- 个人数据：买家的姓名、地址、联系方式属于个人数据，受数据保护法规约束，不应采集。
- 过高的请求频率：影响站点正常运行的密集请求，性质会从”读取公开信息”变成”干扰服务”。
一句话判断标准：数据是否公开可见、是否非个人。与用 API 还是爬虫无关。用官方接口违规使用 PII 同样是违规；采集完全公开的页面同样可以是合规的。
三、公开数据与私有数据：一条比方法更重要的分界线
把这条分界线画出来，架构决策就清楚了。下面按数据域归类，而不是按获取方法归类。
| 数据类别 | 具体内容 | 属性 | 应走路线 |
|---|---|---|---|
| 商品事实 | 标题、品牌、价格、评分、变体、库存状态、BSR | 公开可见 | 公开页采集 |
| 搜索与广告 | 关键词、自然位次、广告位次、广告类型、素材 | 公开可见 | 公开页采集 |
| 评论内容 | 评分、正文、日期、是否验证购买、变体归属 | 公开可见 | 公开页采集 |
| 榜单与类目 | Best Sellers 排名、类目树、筛选条件 | 公开可见 | 公开页采集 |
| 订单与履约 | 订单明细、配送状态、退货 | 账户私有 | SP-API（授权） |
| 买家信息 | 姓名、地址、联系方式 | 账户私有 + 个人数据 | SP-API（需 PII 受限角色） |
| 库存与结算 | 库存明细、结算报表、费用 | 账户私有 | SP-API（授权） |
| 自家广告表现 | 花费、曝光、点击、ACOS | 账户私有 | SP-API（授权） |
注意最后一列：路线是由数据属性决定的，不是由偏好决定的。这也解释了为什么”能不能只用官方 API”这个问题在多数团队里答案是否定的——你需要市场数据，而它不在官方接口的授权范围内。
公开页字段样本
公开页面能结构化的典型字段如下，可以看到这些字段全部属于”公开可见、非个人”范畴：
{
"asin": "B0CXYZ1234",
"marketplace": "amazon.com",
"title": "Stainless Steel Insulated Water Bottle, 32 oz",
"price": { "current": 34.99, "currency": "USD", "listPrice": 44.99 },
"rating": { "average": 4.6, "count": 12847 },
"bsr": [ { "category": "Sports & Outdoors", "rank": 128 } ],
"availability": "In Stock",
"sponsored": false,
"fetchedAt": "2026-08-30T10:22:41Z"
}
这里没有任何买家信息，也没有任何需要卖家授权才能看到的内容。这就是公开采集的合规基础。相对地，订单、买家地址、结算明细不会也不可能出现在公开页面上——它们只能通过 SP-API 在卖家明确授权后获取。
四、覆盖、限流与维护成本：同一任务下的横向比较
既然两者不是替代关系，横向比较就应该只在同一任务上进行。以下对比限定在”获取商品与搜索这类公开市场数据”这一个问题上，比较官方接口、自建抓取与专用数据 API。
| 维度 | 官方 SP-API | 自建网页抓取 | 专用 Amazon 数据 API |
|---|---|---|---|
| 能否拿到公开市场数据 | 否（不在授权范围） | 能，受反爬限制 | 能，覆盖已结构化 |
| 覆盖广度 | 仅限自有账户 | 自定义，深页常受限 | 商品/搜索/评论/榜单/广告位 |
| 限流约束 | 按操作限流，需排队重试 | 自担，靠速率控制 | 按配额，通常可协商 |
| 字段口径 | 官方定义，稳定 | 自己定义，随页面漂移 | 业务字段归一，有 schema |
| 维护成本 | 低（跟随官方版本） | 高（反爬/渲染/解析全自担） | 低（解析在接口层） |
| 合规边界 | 最清晰 | 需自行评估 | 公开数据，供应商应说明 |
SP-API 的限流到底意味着什么
SP-API 采用令牌桶（token bucket）限流模型：每个 API 操作有独立的请求速率（rate）与可用配额（quota），配额会按速率持续恢复。部分操作的初始配额与恢复速率还会随卖家的业务规模浮动。这意味着：
- 高频轮询订单或库存时，必须实现排队与退避重试，否则会被限流返回错误。
- 不同操作的配额互不影响，需要按操作分别建模，不能按”总调用量”粗略估算。
- 具体数值会随官方调整变化，实施前应在官方文档中核对当前值，不要沿用旧文档里的数字。
这一点常被忽略：即使官方接口”免费”，限流也会转化为工程复杂度。如果你需要高频、大批量的数据，限流本身就是一个需要设计的工作量。
自建抓取的真实成本
自建的成本不在服务器，而在四类持续投入：反爬维护（检测规则频繁变化）、渲染（越来越多内容依赖 JavaScript）、解析与字段漂移（页面改版后要改选择器并回填历史）、以及故障排查。
折算方法很直接：如果一个团队每月投入 0.3 个人天维护采集链路，按实际人力成本折算，一年下来通常已超过中等数据量的 API 采购费用——而且这笔成本每个季度都会重复发生。
五、混合架构：两条路线如何共存
既然两者互补，生产架构就应该同时容纳它们，并在接入层汇合。推荐的形态：
【授权域 · SP-API】 【公开域 · 数据采集】
订单 / 库存 / 履约 商品 / 搜索 / 评论
结算 / 自家广告表现 榜单 / 类目 / 广告位
↓ ↓
授权与令牌管理 采集 · 渲染 · 解析 · 反爬
↓ ↓
└──────────→【统一接入层】←──────────┘
字段映射 · 类型校验
失败语义分类 · 质量门禁
↓
业务系统 / 数据管道 / AI Agent
三个设计要点：
统一接入层是必须的。两条路线的数据在这里被映射成同一套内部模型，并做类型强校验。上游任一侧发生变化，错误都在这一层被拦截，不会扩散到下游。
失败语义要分开计数。官方接口的限流错误、公开采集的拦截页、两侧共同的字段缺失，应分成三类分别计数与告警。混进一个 error 日志，你就无法判断问题出在配额、反爬还是覆盖。
不要互相替代。最常见的设计错误是试图用公开采集反推自家订单（做不到，也不该做），或用官方接口去估算市场份额（不在授权范围内）。让每条路线只做它数据域内的事。
六、合规清单
正式上线前，建议逐项确认：
1. 只采集公开可见页面，不触碰登录后才可见的内容。
2. 不采集买家姓名、地址、联系方式等个人数据。
3. 遵守 robots 指令，控制请求速率，避免影响站点正常运行。
4. 规模化前留存法律依据与合规评估记录。
5. 保留采集时间戳与来源，便于事后追溯。
官方接口侧
6. 完成开发者注册，通过 LWA 取得卖家明确授权。
7. 按最小必要原则申请角色，PII 相关操作单独申请受限角色。
8. 实现令牌桶限流的排队与退避重试。
9. 遵守数据保护政策，不超范围使用或留存授权数据。
10. 关注官方接口的版本废弃节奏，预留迁移时间。
边界判断口诀：公开可见、非个人 → 可采集；登录可见、含个人信息 → 必须走授权接口；拿不准的，默认按更严格的一侧处理。
七、决策表：按你的任务对号入座
不再纠结路线，直接按任务查表。
| 你的任务 | 数据域 | 建议路线 | 说明 |
|---|---|---|---|
| 同步自家订单与履约状态 | 账户私有 | SP-API | 唯一合规来源，无需第三方 |
| 管理自家库存与结算 | 账户私有 | SP-API | 同上 |
| 监控竞品价格与库存 | 公开市场 | 公开采集 / 专用数据 API | 官方接口不提供 |
| 追踪关键词自然排名 | 公开市场 | 公开采集 / 专用数据 API | 注意广告与自然位次需可区分 |
| 分析竞品广告位与素材 | 公开市场 | 公开采集 / 专用数据 API | 广告位识别能力需单独评估 |
| 做评论洞察与产品改进 | 公开市场 | 公开采集 / 专用数据 API | 需变体归属才可执行 |
| 既有订单又需要竞品监控 | 两者 | 混合架构 | 两侧在接入层汇合 |
| 只需自家经营数据 | 账户私有 | 仅 SP-API | 引入公开数据只增加合规面积 |
最后一行值得强调：如果需求只限于自身经营，就不要引入公开数据采集。这不是保守，而是避免为用不上的覆盖付出额外的合规与维护成本。
常见问题
亚马逊官方 API 和网页抓取，哪个更合规？
两条路线的合规边界不同，不能简单说谁更合规。SP-API 受官方开发者协议与数据保护政策约束，覆盖自有卖家数据；抓取公开页面则受使用条款、robots 指令与速率限制约束。合规与否取决于你采集什么，而非用哪种方法。
官方 SP-API 能拿到竞品数据吗？
不能。SP-API 的授权范围是与你自有卖家账户绑定的数据，包括订单、库存、自家 listing 与自家广告表现。它不提供市场级竞品数据、类目排名或其他卖家的商品信息。竞品与市场情报需要公开页面数据。
抓取亚马逊会不会违反使用条款？
取决于采集的内容与方式。亚马逊使用条款对自动化访问有限制，风险随登录可见页面、个人数据与过高请求频率上升。建议只取公开非个人字段、遵守 robots 指令与速率限制，并在规模化前留存法律依据。
官方 API 和网页抓取可以混用吗？
可以，而且多数生产系统正是这么做的。常见分工是：SP-API 负责账户数据（订单、库存、自家 listing），公开数据源负责竞品、类目、搜索结果与广告位。两者回答的是不同问题，重叠很少。
什么情况下应该只用官方 API，不用抓取？
当需求只限于自身经营时：订单、库存、履约、自家 listing、自家广告表现。此时引入公开数据源只会买到用不上的覆盖，并额外增加不必要的合规面积。
外部参考：Amazon Selling Partner API 官方文档（授权、角色与限流模型）、Amazon 使用条款与 robots 说明、Pangolinfo 服务公开指标。
下一步：先按第七节的决策表把你的任务分成「账户域」与「市场域」两类。市场域需要商品、搜索、评论、榜单与广告位等公开对象时，可用 Amazon Scraper API 与 Amazon Review API；若要让 Agent 直接取数，走 Amazon Data MCP。可以先从 控制台获取 API Key 做一轮验收，或查看 Amazon Data MCP 技术文档。更上层的选型框架见 亚马逊数据 API：商业调研与方案选型完整指南。
