先说爬虫能解决什么，否则后面的内容会像在推销。
一次性的、小批量的、字段简单的需求，自己写一个脚本通常是最快的路。 一百个 ASIN 的标题和价格，做一次就不再做，写半天跑十分钟，比评估接口、注册、接入要快。这种情况下自建是对的。
成本出问题的是另一种：这个脚本跑通之后，有人说"那我们每天跑一次吧"。
从那一刻起，它从一次性开发变成了一条需要维护的数据管道，而四项支出开始计时。
成本一：反爬对抗是持续投入
第一版脚本能跑通，这件事的信息量比大多数人以为的要小。
它证明的是"今天这个页面结构，在这个频率下，从这个位置，是可以取到的"。 这四个条件里，只有第一个在你的控制之下，而它也会变。
真正的支出在稳定性上：脚本昨天好好的，今天返回空数组，没有报错，只是数据少了三分之一。这类问题没有堆栈可以看，只能靠人去比对。而它出现的时间是随机的，通常不在工作日白天。
这项成本的形状是：开发工时是一次性的，排查工时是周期性的，而周期不由你决定。 预算表里最容易漏掉的就是第二项，因为立项时它还不存在。
本文不讨论任何绕过检测的方法。如果一个方案的可行性取决于能否规避对方的技术措施，那需要调整的是方案的边界，不是技术手段。
成本二：数据口径要自己定义
这是最被低估的一项，因为它看起来不像成本。
页面上有 BSR。页面上没有"月销量"。
你能爬到的是模型的输入，不是模型的输出。 想从排名得到销量，你需要一条排名到销量的换算曲线，而这条曲线要用带真实销量标注的样本才能拟合出来——真实销量只在卖家自己的后台里。这不是工程难度问题，是你手上没有这批样本。
同样的问题在很多字段上重复出现：
| 你以为在爬一个字段 | 实际要先做的决定 |
|---|---|
| 价格 | 标价、促销价、还是叠加优惠券后的价？不同卖家展示位置不同 |
| BSR | 大类排名还是小类排名？类目路径有多层，取哪一层 |
| 销量 | 页面上没有。要么不采，要么自己建模 |
| 评分数 | 父体合并计数还是单个子体的 |
| 类目 | 面包屑里的显示名，还是节点 ID？显示名会变，ID 相对稳 |
每一行都是一个必须由人来拍板的定义。接口交付的是一份有定义的契约，爬虫交付的是那天页面上恰好显示的东西。 两个人爬同一个页面，拿到不一样的数字，而且双方都没写错代码——这在自建方案里是常态。
更麻烦的是这些定义通常没被写下来，它们存在于当初写选择器的那个人的脑子里。三个月后没人说得清这一列到底是什么。
关于事实字段和推算字段的分界，销量数据能拿到什么、拿不到什么拆得更细。
成本三：合规与账号风险
这项不是技术问题，所以工程团队的评估里经常没有它。
要考虑的是：平台的服务条款、数据的使用范围、以及这件事和你的卖家账号之间的关系。风险承担方是业务，不是写脚本的人，但立项时往往只有工程侧参与讨论。
给一个务实的做法：在启动之前，让业务方明确回答"如果这条采集链路带来账号层面的问题，谁来承担"。这个问题不需要复杂的答案，但需要有人回答。如果没人愿意回答，这个项目的风险其实没有被真正接受，只是被推迟了。
成本四：维护者离职等于数据断供
前面三项都可以用钱和时间解决。这一项不能。
一套爬虫里真正的知识很少在代码里：为什么这个选择器要这样写、哪个字段在哪个站点上不一样、哪种失败要重试哪种要跳过、上次改版是怎么修的。这些通常没有文档，因为写的时候它们是"显而易见的"。
写这套代码的人离开之后，下一次页面改版就是终点。 不是修不了，是修的成本高到没人愿意批：新接手的人要先反推整套逻辑，而唯一的说明文档就是代码本身。
这个风险和团队规模成反比。三个人的团队里，采集这件事通常只有一个人真正懂。
四项成本的形状
| 一次性 | 周期性 | 不可预测 | |
|---|---|---|---|
| 反爬对抗 | 首版开发 | 排查和修复 | 改版时间 |
| 数据口径 | 定义字段 | 口径漂移的核对 | 页面结构变化 |
| 合规风险 | 一次评估 | — | 风险何时发生 |
| 维护者 | — | 交接和文档 | 离职时间 |
第三列是这张表的重点。可预算的成本不可怕，不可预测的成本才是。 第三方接口的持续成本落在第二列——按调用量走，能算，能随业务增长线性扩展。自建方案的主要成本落在第三列。
这不代表自建一定更贵，而是它的贵法不一样：它不是一笔更大的钱，是一笔你不知道什么时候要付的钱。
什么时候自建仍然成立
判断标准可以只有一条：这个字段是不是只有你需要？
- 是普遍需求 → 大概率已经有接口覆盖，自己爬是在重复造轮子
- 确实只有你的业务需要 → 自建成立，因为没有第二个选项
再加两个条件会更稳：需求是一次性或低频的，以及字段是简单的、不需要口径定义的。三条都满足，写脚本；有任何一条不满足，先去看接口目录。
接口目录46 个接口按商品、关键词、市场、流量、商标分组，先确认你要的字段是否已被覆盖如果还没确定走哪条路，亚马逊数据 API 怎么选对比了官方 SP-API、第三方接口和自建采集三条路各自能拿到什么。这篇是那篇里"自建"那一列的展开。
常见问题
小规模爬取值得吗？ 一次性的、字段简单的需求，值得。变成每天跑的定时任务之后，这四项成本就开始计时了。
爬虫比调接口便宜吗？ 前期便宜，因为只有开发工时。把排查工时、口径核对和维护者风险算进去之后，通常不便宜。关键差别不在总额，在可预测性。
能爬到销量吗？ 页面上没有这个字段。你能爬到的是 BSR，从 BSR 到销量需要一条换算曲线，而拟合曲线需要带真实销量标注的样本，这批样本不在公开数据里。
两边一起用可以吗？ 可以，而且常见。普遍字段走接口，只有你需要的长尾字段自己采，这样自建的部分足够小，前面四项成本都可控。