如何用 Python 爬取 Amazon 产品评论和价格
Amazon 掌握的产品数据，比任何单个研究团队靠人工所能收集的都要多。价格每小时都在变动。评论以数千计地不断累积。如果你想追踪竞争对手、为情感分析模型提供数据，或构建一款价格提醒工具，你就需要 一种自动抓取这些数据的方法.
本指南涵盖了这项工作的两个方面： 仅使用 Python、Requests 和 BeautifulSoup 抓取实时价格和抓取评论。其中大部分工作无需无头浏览器。
读完本文，您将拥有一个可用的抓取程序，能够获取商品详情和评论数据、处理分页、重试失败请求，并将所有内容导出为 CSV。我们还会讲解为什么原始 HTTP 请求在 Amazon 上会被拦截，以及真正有效的解决办法。如果您需要一份新手入门指南，请查看我们的 Amazon 数据抓取教程.
所用技术： requests 用于发起 HTTP 调用，BeautifulSoup 和 lxml 用于解析，pandas 用于导出干净的数据集。
大多数亚马逊抓取教程都会选边站。它们要么专注于价格，把评论当作次要的补充；要么深入研究评论文本，完全跳过价格。这种割裂与数据的实际使用方式并不相符。一个没有评论背景的价格数据集只能告诉你东西值多少钱，却无法说明买家为什么会选择某个商品列表而不是另一个。本指南将两者视为同等重要， 每一项都有专门的步骤、专门的代码和专门的故障排查.
为什么要抓取 Amazon 的产品评论和价格？
Amazon 产品页面是互联网上最丰富的公开数据来源之一。单个商品列表就能告诉你价格、划线价所暗示的折扣历史、星级评分，以及真实买家的看法。
这里就是这些数据实际派上用场的地方。
- 电商定价。 卖家会追踪竞争对手的价格，以保持在Buy Box中的排名。
- 竞争对手监控。 各品牌都在关注竞争对手如何为同类产品定价和进行市场定位。
- 价格追踪工具。 优惠网站和浏览器扩展依赖于历史价格数据。
- 情感分析。 评论揭示了客户真正抱怨的问题，而不是营销文案所宣称的内容。
- 市场调研。 覆盖整个品类的评论和价格数据，能在需求趋势出现在销售报表之前就将其暴露出来。
- AI 训练数据集。 结构化的产品和评论文本对于构建推荐模型和 NLP 数据集非常有用。
价格和评论回答的是不同的问题。价格数据告诉你市场愿意支付多少。评论数据告诉你客户为何购买,或为何退货。你通常需要两者兼备,才能勾勒出完整的画面。
以一位追踪竞争对手商品的卖家为例。价格能告诉他们本周自己的定价是偏低还是偏高。评论则能告诉他们竞争对手是否在质量、发货速度或包装上更胜一筹，而这些都无法仅凭价格数据体现出来。
把两组数据集都拉取下来，你就能更全面地了解为什么某个商品列表的表现优于你的。
你可以提取哪些 Amazon 数据?
我们把它拆分成两个数据集。每个数据集对应产品页面的不同部分。
产品数据
| 字段 | 描述 |
| 标题 | 完整商品名称 |
| 当前价格 | 此刻向买家展示的价格 |
| 原价 | 折扣前的标价（如有显示） |
| 折扣 | 折扣百分比，可以计算得出或直接抓取 |
| 评分 | 5 分制的平均星级评分 |
| 评论数量 | 评分总数 |
| 可用性 | 有货、库存有限或缺货 |
| 品牌 | 制造商或店铺名称 |
| ASIN | Amazon 的唯一产品标识符 |
评论数据
| 字段 | 描述 |
| 作者 | 评论者的显示名称 |
| 评论标题 | 评论者撰写的简短标题 |
| 评论正文 | 评论的完整正文 |
| 评分 | 评论者给出的星级评分 |
| 已验证购买 | Amazon 是否确认买家购买了该商品 |
| 评论日期 | 评论发布的日期 |
| 图片 | 评论所附任何照片的 URL |
两个数据集共享一个键，即 ASIN. 这正是让你随后能够在 pandas 中关联产品数据和评论数据的关键。
抓取 Amazon 时的常见挑战
Amazon 是最难可靠抓取的网站之一，而且难度随着时间推移不断加大。以下是你会遇到的情况。
改变 HTML 结构
Amazon 会不断对页面布局进行 A/B 测试。今天有效的选择器，下周可能什么都返回不了。请把你的抓取器设计成在某个字段返回为空时会明确报错，而不是悄无声息地失败。
做一次快速的合理性检查，比如在保存一行数据前确认标题字段不为空，就能在这些异常污染你的数据集之前拦下其中的大多数。
CAPTCHA 和机器人验证
当亚马逊将某个请求标记为自动化请求时，它会用一个“Robot Check”页面替换掉产品页面。棘手的是，这个页面仍然返回 HTTP 200。你的脚本会以为请求成功了，然后却在 HTML 中找不到标题、找不到价格，也找不到评论。这就是为什么仅靠状态码检查还不够。 你还需要验证抓取到的内容是否确实对应一个真实的产品页面。
HTTP 403 和 503 响应
403 通常意味着你的请求被直接拒绝，往往是因为缺少请求头或请求头可疑。503 则意味着服务器拒绝提供该页面，有时是一种软性的速率限制信号，而非硬性封锁。在重试逻辑中区别对待这两种情况，而不是把所有非 200 的响应一概而论，能让你更清楚地了解到底哪里出了问题。
速率限制与IP信誉
从一个 IP 发送过多、过快的请求，亚马逊就会对你进行限速或封禁。IP 的历史记录也很重要。一个 住宅 IP 从未发出过异常请求的 IP，比一个有抓取历史的数据中心 IP 更受信任。
Amazon 的系统如今会综合权衡多个信号，包括请求速率、请求头一致性和浏览模式，而不再依赖任何单一触发条件来标记某个会话。
动态定价与地区定价
价格会因库存水平、时段乃至买家的表面所在地而变化。你用美国 IP 抓取到的价格，可能与英国 IP 在同一商品页面上看到的不同。如果你的使用场景依赖地区准确的价格，这就不是一个小细节。如果你不能控制请求看起来源自何处，它会悄然扭曲整个价格数据集。
项目搭建
让我们来安装所需的组件。 打开一个终端并运行：
以下是每一项被纳入技术栈的原因：
- requests: 负责发送HTTP请求，并处理请求头、cookie和会话。
- beautifulsoup4: 将 HTML 解析为一棵可搜索的树,以便你提取特定的标签和属性。
- lxml: 一个 BeautifulSoup 在底层使用的快速解析引擎。在处理大型页面时，它明显比默认的 Python 解析器更快。
- pandas: 能把你抓取到的字典和列表转换成整洁的表格，然后导出为CSV。
创建一个包含两个文件的项目文件夹: scraper.py 负责处理逻辑，还有一个空的 output/ 用于存放 CSV 导出文件的文件夹。
第 1 步。查找产品 ASIN
每件 Amazon 商品都有一个 ASIN（Amazon 标准识别码）。它是一个 10 位字符的编码，能唯一标识某个商品，与 URL 别名或市场域名无关。
你可以在 URL 中紧随其后的位置发现它 /dp/ 或 /gp/product/:
一个简短的辅助函数用正则表达式将其提取出来:
获取到 ASIN 后，你可以为商品页面和评论页面重新构建干净的规范 URL，从而避免跟踪参数堆积、扰乱请求的问题。
第 2 步。向 Amazon 发送请求
一个不加任何修饰的 requests.get(url) 调用在亚马逊上几乎总会失败。你需要类似真实浏览器的请求头、一个超时设置以防卡住的请求让你的脚本永远挂起，以及一个针对那些仍然失败的请求的重试策略。
重要的请求头
最重要的请求头是 User-Agent。如果没有它，Amazon在几毫秒内就能识别出该请求来自脚本。 Accept-Language 和 接受 共同构成一组更接近真实浏览器标签页的请求头。
超时与重试策略
没有设置超时的请求在服务器停滞时可能会无限期挂起。带退避的重试循环可以在不猛烈冲击服务器的情况下处理诸如 503 之类的临时性故障。
注意在退避时间中加入了随机抖动。固定的延迟模式本身就是一种机器人信号。稍微将其随机化会让你的流量更难被指纹识别。
第 3 步。抓取产品价格和信息
拿到有效的 HTML 响应后，就该对它进行解析了。Amazon 把大多数产品数据包裹在可预测的元素 ID 中，不过类名的变动更为频繁。
关于这些选择器的几点说明：
- 价格被拆分到两个 span 中,即整数部分和小数部分。Amazon 这样做是为了让美分部分的样式比美元部分显得更小。
- 原价只在有正在进行的折扣时才会出现。如果选择器什么都没返回，请将其视为“无折扣”而不是错误。
- 评分文字类似“4.5 out of 5 stars”（5星中的4.5星）。 按 “out of” 拆分比直接尝试解析数字更可靠，因为空格间隔各不相同。
注意： if text_or_none(“#productTitle”) 返回为空，那么你很可能遇到的是 Robot Check（机器人验证）页面，而不是某个字段缺失。在信任其余解析数据之前，请务必检查标题是否为 null。
抓取当前价格只是第一步。要监控价格随时间的变化,请查看我们关于构建 Amazon价格追踪器 它会存储历史价格并发送降价提醒。
第 4 步。抓取 Amazon 商品评论
评论存放在一个单独的 URL 模式下，通常是 /product-reviews/{ASIN}。每条评论都位于一个重复的区块内,这使它非常适合对匹配的元素进行循环遍历。
该 data-hook 属性在这里比类名更稳定。Amazon 内部使用它们进行分析，因此它们往往比 CSS 类更能经受住布局的变化。
商店 image_urls 暂时先用列表形式保存。我们会在导出前将其展平为逗号分隔的字符串，因为 CSV 单元格更适合存放纯字符串，而不是嵌套列表。
第 5 步。处理多个评论页面
一件热门商品可能有成千上万条评论，分布在数十个页面上。你需要分页逻辑、请求之间的延迟，以及明确的停止条件，这样抓取程序才不会一直运行下去。
这里有三点很重要：
- 停止条件。 空白的评论页面意味着你已经抓取到了末尾，而不是出错。应当干净利落地停止，而不是无休止地循环下去。
- 请求之间的延迟。 在翻页之间随机停顿2到5秒，可以让你的请求模式看起来不那么机械化。
- 最大页数上限。 即使是极受欢迎的产品，也不需要抓取每一条评论。将上限设定在一个合理的数值，比如 20 页，可以让运行时间保持可预测。
第 6 步。将所有内容导出为 CSV
Pandas 让导出这一步几乎变得轻而易举。将你的字典列表转换为 DataFrame，清理评论图片列，然后写入 CSV。
当你希望每一条评论旁边都附带产品背景信息时，合并文件就很有用，例如在训练一个情感分析模型时，该模型还需要了解被评论产品的价格区间。
完整的 Python 抓取器
以下是把所有部分整合到一个脚本中的完整代码。将其保存为 scraper.py 并直接运行它。
重要提示
Amazon 会频繁更新其 HTML 结构、CSS 选择器和反爬虫防护。文中的示例在 本指南演示了整体抓取工作流程，但个别选择器或请求模式可能需要随时间推移进行更新。如果你的抓取工具开始返回空结果或缺失字段，请检查最新的页面源代码，调整选择器，并确认 Amazon 没有返回 CAPTCHA 或机器人验证页面来代替所请求的内容。
常见错误与故障排查
网页抓取并非一次性的实现工作。Amazon 会定期更改其页面布局、尝试 A/B 测试并加强反机器人防护。即使是今天能正常运行的抓取工具，将来也可能需要对选择器进行小幅更新。
| Symptom | 可能的原因 | 修复 |
| HTTP 403 | 缺失或可疑的请求头 | 添加真实可信的 User-Agent 和 Accept-Language 请求头 |
| HTTP 503 | 软性速率限制或线路过载 | 带抖动地退避,降低请求速率 |
| 页面加载了，但字段为空 | 机器人验证页面，而不是真实的商品列表 | 检查标题是否为 null,轮换 IP,添加代理 |
| 稳定抓取数周后选择器突然失效 | Amazon 在一次 A/B 测试中更改了布局 | 重新检查页面,更新选择器,添加备用选择器 |
| 空的 HTML 响应 | 连接在请求过程中被中断或阻止 | 用 try/except 包裹请求，并使用全新的会话重试 |
| 价格与你在浏览器中看到的不同 | 与IP位置挂钩的区域定价 | 使用位于目标国家/地区的代理 |
| 翻了几页之后评论数量不再增长 | 达到了 max_pages 上限，或者评论确实已经抓取完毕 | 在断定是 bug 之前，先检查解析出的列表是否为空 |
如何扩展 Amazon 抓取规模
在你笔记本上适用于单个产品的脚本，在每天处理 10,000 个产品时的表现会截然不同。扩展规模意味着要在处理海量请求的同时，不触发亚马逊的防护机制。
轮换 IP
来自同一个 IP 的每一次请求都会累加到该 IP 的风险评分上。通过在庞大的 IP 池中轮换，可以分散你的请求量，从而使任何单个地址都不会显得可疑。
粘性会话
轮换并不总是正确的做法。翻阅单个产品的评论时，在该会话期间使用单一、稳定的 IP 效果更好，因为在会话中途切换 IP 本身就可能显得不自然。
真实的浏览器请求头
保持你的请求头集合处于最新状态。User-Agent 字符串中的浏览器版本很快就会过时，而过时的版本很容易被识别出来。
随机延迟和重试逻辑
我们已经介绍过抖动（jitter）和退避（backoff）。在大规模操作时，请对整个请求队列应用同样的逻辑，而不仅仅是在单个产品的评论页面内。
并行抓取与会话保持
并发运行请求可以加快速度，但每个工作线程或进程都需要自己的会话，理想情况下还需要自己的 IP。在多个并发工作线程之间混用共享会话是意外触发速率限制的常见原因。
正是在这里，代理基础设施变得不再可有可无。一个每天发出数千次请求的数据中心 IP 会很快被标记，无论你的请求头和重试逻辑做得多好。
住宅代理 将你的流量路由到真实的家庭 IP 地址，与服务器托管的 IP 相比，这类地址在 Amazon 的机器人检测中被判定的风险分数要低得多。
移动代理 在应对最棘手的目标时更进一步,比如卖家资料页面或按地区锁定的搜索结果,因为运营商 IP 由成千上万部真实手机共享,很少会被大范围封锁。
无论哪种方式，抓取代码都完全相同。唯一改变的是背后使用的是哪个 IP 地址 requests.Session 对象,通常通过传入每个请求的 proxies 字典进行配置。 这只是很小的代码改动，却能在大规模抓取时带来可靠性的大幅提升.
为什么使用 NodeMaven 进行 Amazon 抓取?
上一节的所有内容都指向同一个结论。即使你的代码完美无缺，如果你的 IP 看起来有问题，你仍然会被封锁。NodeMaven 正是围绕解决这一具体问题而打造的。
地理定向. 按国家、城市或 ZIP 邮编定位，当你需要查看特定地区的买家会看到的确切价格时，这一点尤为重要。
粘性会话。 在评论翻页任务需要的时间内保持使用同一个 IP，然后为下一个商品轮换 IP。
IP 质量过滤。 每个 IP 在交付给你之前都会经过检测，从而减少了困扰廉价代理池的那些失效或已被标记的地址。
这一切都无法替代良好的抓取器设计。重试逻辑、请求头和节奏控制依然重要。但把可靠的代码与专为抓取打造的代理池搭配使用，才能让一个只能撑一下午的脚本，变成每天都能稳定运行的程序。
