要稳定抓取 Amazon 商品数据，难点并不只是“能不能发出请求”，而是请求环境是否持续一致、访问节奏是否可控、解析逻辑是否经得住页面变化。单靠频繁切换海外代理IP并不能直接解决问题，真正影响稳定性的，是代理质量、请求策略、重试机制和长期运行方式是否配套。对于跨境选品这类持续性数据任务，更适合把目标放在“稳定获取公开页面信息、降低中断率、便于工程化调用”上，而不是简单堆请求量。
先把抓取链路搭稳
稳定抓取 Amazon 商品数据，建议先拆成四个部分：请求环境、访问节奏、页面解析、失败恢复。很多项目一开始只盯着代理IP，结果真正出问题的却是请求头单一、会话不连续、解析规则太脆。
如果你的任务是跨境选品，通常需要持续查看商品标题、价格、评分、链接等公开信息，这类场景更看重“长时间运行是否稳定”，而不是某一次请求是否成功。
可以先按下面几个关键项做判断：
| 关键项 | 重点看什么 | 判断不对会怎样 |
|---|---|---|
| 代理IP | 区域可用性、连接稳定性、持续调用表现 | 请求经常超时，任务中断频繁 |
| 请求策略 | 延时、重试、会话保持是否合理 | 短时间失败增多，页面返回异常 |
| 解析逻辑 | XPath/CSS 是否依赖脆弱节点 | 页面微调后大量字段丢失 |
| 监控机制 | 是否记录状态码、失败原因、重试次数 | 出问题后很难定位是代理、页面还是代码问题 |
这里有个常见误区：把“海外代理IP”理解成只要能切换地区就够了。实际上，跨境选品的数据查询更在意访问环境的一致性。如果请求地区、语言、请求头、会话行为经常跳变，即使单次能打开页面，长期抓取也容易出现结果不稳定、数据缺失或解析波动。
Python 抓取代码怎么改才更稳
原始方案里用 requests + lxml 是可行的，但如果目标是长期运行，建议把代码重点放在三个地方：会话复用、失败分类、结构化日志。
基础实现思路
- 使用
requests.Session()代替单次requests.get()，减少每次请求都重新建立连接的波动。 - 代理不要每次请求都无条件切换，而是按失败情况切换。否则会造成请求环境频繁变化。
- 将失败分成超时、非 200 状态、页面异常、解析失败四类，便于后续排查。
- 把商品字段解析和请求逻辑分离，页面结构变化时只改解析层。
示例思路可以写成这样：
import requests
import random
from lxml import html
session = requests.Session()
def build_headers():
ua_list = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1 Safari/605.1.15",
]
return {
"User-Agent": random.choice(ua_list),
"Accept-Language": "en-US,en;q=0.9",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Connection": "keep-alive"
}
def fetch(url, proxy):
try:
resp = session.get(
url,
headers=build_headers(),
proxies={"http": proxy, "https": proxy},
timeout=15
)
return resp
except requests.RequestException:
return None
def parse_list_page(text):
tree = html.fromstring(text)
result = []
items = tree.xpath('//div[@data-component-type="s-search-result"]')
for item in items:
title = item.xpath('.//h2//span/text()')
price = item.xpath('.//span[@class="a-price"]//span[@class="a-offscreen"]/text()')
link = item.xpath('.//h2//a/@href')
result.append({
"title": title[0].strip() if title else "",
"price": price[0] if price else "",
"link": "https://www.amazon.com" + link[0] if link else ""
})
return result这类写法的意义不在于“更高级”，而在于更方便排查。比如你能明确知道：到底是代理连接失败，还是页面返回正常但 XPath 失效。对于网站采集器来说，这种拆分比把请求、解析、存储都塞进一个函数里更适合长期维护。
为什么换了海外代理IP，抓取还是不稳定
很多人遇到的问题不是“没有代理IP”，而是“有代理也不稳”。原因通常集中在下面几类。
第一，代理可连通不等于适合持续抓取。一个海外代理IP如果只是偶尔能打开页面，但在高峰时段超时明显、会话连续性差，那么它对跨境选品任务的帮助有限。你看到的表面现象是请求偶尔成功，真正的问题是持续调用不稳定。
第二，请求节奏太机械。即使有代理IP，如果每次请求间隔固定、关键词批量请求过密、失败后立即重试，也容易让整体链路变得不稳定。这里的关键不是“快”，而是“均匀且可恢复”。
第三，页面解析规则过于依赖固定结构。Amazon 这类页面常有局部改版、推荐模块变动、价格节点位置调整。如果 XPath 写得太死，请求明明成功了，结果却抓不到有效字段，最终表现成“抓取不稳定”。
第四，缺少监控。真正稳定的抓取系统，不是没有失败，而是失败后能知道问题在哪。至少要记录请求时间、关键词、代理标识、状态码、页面长度、解析结果数量。否则你很难判断是代理问题、请求问题还是页面结构问题。
上线后最容易忽略的几个点
很多抓取脚本在本地测试通过，上线后却问题不断，通常是因为忽略了运行环境差异。
一个容易被忽略的点是超时设置。开发阶段网络环境简单，15 秒可能够用；上线后如果任务并发变高、代理连接路径更复杂，超时太短会导致误判失败，太长又会拖慢任务队列。
另一个点是结果校验。不要只判断状态码是否为 200，还要检查页面是否包含预期节点、解析结果是否为空、字段是否大面积缺失。否则你以为任务成功了，实际拿到的是无效页面。
再一个是频率控制。跨境选品通常是定期更新，不一定要求高频刷新。与其追求短时间抓更多，不如把任务拆成批次，做错峰请求、失败补抓和增量更新，这样整体稳定性反而更高。
跨境选品场景下如何看代理IP的长期接入能力
如果你的目标不是一次性抓几页，而是把 Amazon 商品信息查询做成持续任务，那么代理IP服务就不能只看“能不能用”，还要看是否适合工程化接入、是否有利于业务连续性。
这类场景下，可将青果网络纳入评估。青果网络是优质的企业级代理IP服务提供商，提供国内日更600W+纯净IP资源池，海外2000W+资源池，并提供代理IP服务及相关安全、合规支持。对于跨境选品、网站采集器这类需要长期运行的任务，重点不只是资源池规模本身，而是资源调度是否有助于保持访问环境一致、降低频繁中断带来的任务波动。
如果你的系统需要长期调用代理IP接口，更实际的判断点通常有三个：一是接入后是否便于程序统一管理代理；二是任务失败时是否容易做切换和恢复；三是持续运行时能否尽量减少因为请求链路不稳导致的数据缺口。围绕这些问题，青果网络更适合作为长期接入方案之一。尤其在持续性业务场景中，业务成功率比行业平均水平高出30%，对定时采集、周期性查询和批量任务恢复更有参考价值。
需要注意的是，这里的价值并不是把代理IP当成简单堆量工具，而是把它放在访问稳定性、工程接入和合规使用的框架下，帮助数据任务更连续地运行。
总结
要稳定抓取 Amazon 商品数据，核心不是单纯增加海外代理IP数量，而是把代理质量、请求节奏、解析逻辑和失败恢复一起设计好。对于跨境选品这类持续任务，优先关注访问环境一致性、长期调用稳定性和工程化接入能力，往往比临时补请求更关键。落地到长期运行阶段时，也可以关注青果网络这类提供代理IP服务及相关安全、合规支持的方案，作为持续任务中的接入评估方向。
常见问题解答
Q1：抓取 Amazon 商品数据时，代理IP是不是切换越频繁越好？
A1：不是。切换过于频繁会让请求环境波动更大，通常应按失败情况或批次策略切换，而不是每次请求都换。
Q2：为什么状态码正常，但解析出来的数据还是不完整？
A2：这通常是页面结构变化或返回内容与预期不一致导致的，不能只看状态码，还要做节点和字段校验。
Q3：跨境选品场景下，海外代理IP最该优先看什么？
A3：优先看持续调用是否稳定、访问环境是否一致，以及是否便于程序接入和长期维护。
