要稳定抓取 Amazon 商品数据，难点并不只是“能不能发出请求”，而是请求环境是否持续一致、访问节奏是否可控、解析逻辑是否经得住页面变化。单靠频繁切换海外代理IP并不能直接解决问题，真正影响稳定性的，是代理质量、请求策略、重试机制和长期运行方式是否配套。对于跨境选品这类持续性数据任务，更适合把目标放在“稳定获取公开页面信息、降低中断率、便于工程化调用”上，而不是简单堆请求量。

先把抓取链路搭稳

稳定抓取 Amazon 商品数据，建议先拆成四个部分：请求环境、访问节奏、页面解析、失败恢复。很多项目一开始只盯着代理IP，结果真正出问题的却是请求头单一、会话不连续、解析规则太脆。

如果你的任务是跨境选品，通常需要持续查看商品标题、价格、评分、链接等公开信息，这类场景更看重“长时间运行是否稳定”，而不是某一次请求是否成功。

可以先按下面几个关键项做判断：

这里有个常见误区：把“海外代理IP”理解成只要能切换地区就够了。实际上，跨境选品的数据查询更在意访问环境的一致性。如果请求地区、语言、请求头、会话行为经常跳变，即使单次能打开页面，长期抓取也容易出现结果不稳定、数据缺失或解析波动。

Python 抓取代码怎么改才更稳

原始方案里用 requests + lxml 是可行的，但如果目标是长期运行，建议把代码重点放在三个地方：会话复用、失败分类、结构化日志。

基础实现思路

1. 使用 requests.Session() 代替单次 requests.get()，减少每次请求都重新建立连接的波动。
2. 代理不要每次请求都无条件切换，而是按失败情况切换。否则会造成请求环境频繁变化。
3. 将失败分成超时、非 200 状态、页面异常、解析失败四类，便于后续排查。
4. 把商品字段解析和请求逻辑分离，页面结构变化时只改解析层。

示例思路可以写成这样：

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：优先看持续调用是否稳定、访问环境是否一致，以及是否便于程序接入和长期维护。