做亚马逊数据接入，几乎每个团队都会先吵一轮：用官方 API 还是自己爬？
吵的内容大同小异——官方更合规但配额少，抓取覆盖广但会被封，然后翻一堆文章看别人的对比表，最后靠某个人的直觉拍板。
这个决策之所以难产，是因为问题被问错了。它预设两者是同一件事的两种实现，于是比较就退化成"谁更合规、谁更便宜、谁更稳"。
但真相是：**它们获取的是两类不同的数据。**想清楚这一点，路线之争就消失了。
一、为什么"二选一"不成立
看两者的授权范围就明白了。
官方 SP-API 的授权严格绑定在你的卖家账户上：订单、库存、履约、自家 listing、自家广告表现。它回答的是"我的生意现在怎么样"。
公开页面采集能拿到的是：商品信息、搜索结果、评论、榜单排名、广告位。它回答的是"市场现在怎么样"。
这是两个问题，数据域几乎不重叠。
你不会因为"官方 API 更合规"就用它去查竞品价格——它在设计上就不提供这些数据。你也不会因为"抓取覆盖更广"就用它去拉自己的订单——订单在登录之后，属于账户私有数据。
所以正确的问法不是"选哪个"，而是：我的哪些需求属于账户域，哪些属于市场域？
前者走官方接口，后者走公开数据。绝大多数团队的答案是：两个都有。
二、合规边界：取决于采什么，不是用什么方法
合规讨论最容易滑向"哪个更合法"这种无解的比较。
实际上两条路线的合法性来源完全不同：
官方 SP-API：协议授权
合法性来自显式协议链：开发者注册 → 卖家通过 Login with Amazon 授权 → 应用通过角色获得最小必要权限。涉及个人身份信息（PII）的操作需要单独申请受限角色并通过审核。
违反的是开发者协议与数据保护政策，后果是授权被撤销。
边界很清晰，但也很窄：只有卖家主动授权给应用的那部分数据。
公开页面采集：条款与 robots 约束
不由协议授权，而是落在平台使用条款、robots 指令与速率限制的约束下。
没有一纸合同，但不等于禁止——公开可见、非个人的页面信息原则上可以采集，这是行业长期实践。
风险随三件事上升：
**登录可见内容。**登录后才能看到的页面，明显越过了"公开"这条线。这是最硬的红线，没有模糊空间。
**个人数据。**买家的姓名、地址、联系方式属于个人数据，受数据保护法规约束，不应采集。注意这一条与用什么方法无关——用官方接口违规使用 PII 同样是违规。
**过高的请求频率。**影响站点正常运行的密集请求，性质会从"读取公开信息"变成"干扰服务"。这不只是技术问题，也是性质问题。
**一句话判断标准：数据是否公开可见、是否非个人。**跟用 API 还是爬虫没有关系。
三、一条比方法更重要的分界线
把数据按域归类，而不是按获取方法归类，架构决策就清楚了。
| 数据类别 | 具体内容 | 属性 | 应走路线 |
|---|---|---|---|
| 商品事实 | 标题、品牌、价格、评分、变体、库存状态、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 在卖家明确授权后获取。
四、SP-API 的限流，是工程问题不是成本问题
这一点常被忽略：即使官方接口免费，限流也会转化为工程复杂度。
SP-API 采用令牌桶（token bucket）限流模型：每个 API 操作有独立的请求速率（rate）与可用配额（quota），配额按速率持续恢复。部分操作的初始配额与恢复速率还会随卖家业务规模浮动。
三个必须注意的点：
**不同操作的配额互相独立。**这是最常见的设计失误——按"总调用量"估算一定错。getOrders 和 getInventorySummaries 是两套桶，要分别建模。
**被限流不是异常，是正常状态。**高频轮询时限流几乎必然发生，正确做法是排队 + 退避重试，而不是让它抛异常炸掉任务。
**数值会变。**具体配额与速率会随官方调整变化，实施前请在官方文档核对当前值。我见过团队照着一年前的文档设计配额，上线第一天就被限流打满。
顺带说一个实现细节：服务端如果返回了 Retry-After 头，优先用它，比自己的退避算法更准确。另外只对 429 和 5xx 重试——400/401/403 这类是参数或授权问题，重试一百次也不会成功，只会浪费配额。
五、混合架构：两条路线怎么共存
既然互补，生产架构就应该同时容纳它们，并在接入层汇合：
【授权域 · SP-API】 【公开域 · 数据采集】
订单 / 库存 / 履约 商品 / 搜索 / 评论
结算 / 自家广告表现 榜单 / 类目 / 广告位
↓ ↓
授权与令牌管理 采集 · 渲染 · 解析 · 反爬
↓ ↓
└─────────→【统一接入层】←────────┘
字段映射 · 类型校验
失败语义分类 · 质量门禁
↓
业务系统 / 数据管道 / AI Agent
三个设计要点：
**统一接入层是必须的。**两条路线的数据在这里映射成同一套内部模型，并做类型强校验。上游任一侧变化，错误都在这一层被拦截，不会扩散到下游。这一层也是隔离供应商变化的屏障——将来换数据源只改映射层。
**失败语义要分开计数。**三类失败必须分别统计：
throttled/request_error— 请求层问题，看配额和退避blocked— 拿到 200 但不是正常页面（公开采集侧特有）incomplete— 解析成功但缺字段（覆盖问题）
这三类的修法完全不同。混进一个 error 日志，你就无法判断该去调配额、换代理还是找供应商补字段。
**blocked 必须在内容层检测。**被拦截的页面同样返回 HTTP 200。只判断状态码，脏数据就会带着"成功"的标签流进数据库——这是我们踩过的最贵的一个坑。
**不要互相替代。**最常见的设计错误是试图用公开采集反推自家订单（做不到，也不该做），或用官方接口估算市场份额（不在授权范围内）。让每条路线只做它数据域内的事。
六、决策表：按任务对号入座
不用再纠结路线，直接查表：
| 你的任务 | 数据域 | 建议路线 | 说明 |
|---|---|---|---|
| 同步自家订单与履约状态 | 账户私有 | SP-API | 唯一合规来源，无需第三方 |
| 管理自家库存与结算 | 账户私有 | SP-API | 同上 |
| 监控竞品价格与库存 | 公开市场 | 公开采集 / 专用数据 API | 官方接口不提供 |
| 追踪关键词自然排名 | 公开市场 | 公开采集 / 专用数据 API | 注意广告与自然位次需可区分 |
| 分析竞品广告位与素材 | 公开市场 | 公开采集 / 专用数据 API | 广告位识别能力需单独评估 |
| 做评论洞察与产品改进 | 公开市场 | 公开采集 / 专用数据 API | 需变体归属才可执行 |
| 既有订单又需要竞品监控 | 两者 | 混合架构 | 两侧在接入层汇合 |
| 只需自家经营数据 | 账户私有 | 仅 SP-API | 引入公开数据只增加合规面积 |
最后一行值得单独强调：如果需求只限于自身经营，就不要引入公开数据采集。
这不是保守。架构复杂度应该与问题复杂度匹配——两条通道的汇合是有成本的，只有当需求确实横跨两个数据域时，这笔成本才值得付。为了"以后可能用得上"提前建一套，通常只会得到一套没人维护的僵尸链路。
七、落地顺序：先划域，再建接入层，最后才碰采集
讲了这么多，给一个实操顺序。这个顺序颠倒过一次就会返工，值得单独强调。
**第一步：划数据域（半天）。**把需求清单摊开，逐条标注"账户域"还是"市场域"。这一步不做，后面所有技术讨论都是在赌。
**第二步：建统一接入层（2–3 天）。**先定义内部模型与字段映射表，再实现类型强校验与三类失败分类。注意这一步要在两条链路之前做——它是两条通道的汇合点，先建好才能让后续链路直接对接。
**第三步：接 SP-API（3–5 天）。**按官方文档核对各操作的速率与配额，实现令牌桶排队与退避重试。数值以官方文档当前值为准，不要沿用旧文档里的数字。
**第四步：接公开数据（1 周左右）。**实现采集、blocked 内容层检测、解析与字段归一。
**第五步：灰度对齐（2 周）。**两条链路并行跑，重点看历史数据能否对齐。字段口径不一致要在这步暴露，不要等全量切换后发现趋势图断崖。
最常见的返工是跳过第一步直接建链路，做到一半发现需要的数据不在这一条上，再加第二条——此时两套字段口径已经对不上，要额外做映射与历史对齐。
第二常见的返工是先建采集链路再补接入层。结果接入层上线时，采集链路要改一遍对接内部模型，等于重做。
顺序对了，整个工作量能省掉三分之一。
小结
把边界画在"数据"上，而不是"方法"上，整个决策会简单很多：
- 把需求清单摊开，逐条标注"账户域"还是"市场域"
- 账户域走 SP-API，注意令牌桶限流要按操作分别建模
- 市场域走公开采集，注意 blocked 必须在内容层检测
- 两条路在统一接入层汇合，失败分三类分别计数
- 需求只在单侧时，不要建混合架构
产品上，市场域的公开对象可用 Amazon Scraper API 与 Amazon Review API 覆盖；Agent 直连走 Amazon Data MCP。想实测可以去 控制台 拿 Key，或看 Amazon Data MCP 文档。
完整对比（授权边界、公开与私有数据分界、混合架构与决策表）在这篇：亚马逊API 与网页抓取对比：比较与技术决策完整指南。
如果你正在划这条线，评论区说说你的任务清单，我可以帮你标一遍哪些走账户域、哪些走市场域。
