返回博客

2026年Mercado Libre数据解析:为什么解析器收集的价格不在正确区域

Mercado Libre 为所有未设置配送区域的用户提供默认索引,并根据该索引计算价格、免费配送和买家盒子的赢家。公共 API 端点返回 403 PolicyAgent,展示界面通过自身的设备检查进行验证。我们将基于经过验证的事实,探讨如何正确收集关于七个 Mercado Libre 展示界面的数据,以及需要哪些代理。

📅2026年9月12日
2026年Mercado Libre数据解析:为什么解析器收集的价格不在正确区域

您已导出 40,000 张 Mercado Libre 的卡片,计算了阿根廷的平均价格并提交了报告。问题在于,这并不是阿根廷的价格。这是邮政编码 1430 的价格——这是平台为所有未指定送货地址的用户提供的默认区域。

Mercado Libre 在拉丁美洲的 18 个国家运营,2025 年集团的收入达到了 289 亿美元,员工人数为 123,670 人。对于电子商务分析而言,这是该地区的主要数据来源,同时也是最被低估的陷阱:平台根据请求来源和会话看到的送货区域提供不同的价格、不同的送货方式和不同的买家盒子赢家。我们来分析一下具体出现了什么问题,以及如何正确收集数据。

2026 年的变化:API 实际上已关闭

几年前,“解析 Mercado Libre”可以通过公共 API 实现:GET api.mercadolibre.com/sites/MLA/search?q=iphone 可以在不需要授权的情况下返回结果。今天情况已经不同了。

2026 年 9 月 12 日的检查结果显示,使用普通服务器 IP,没有令牌:

  • /sites — HTTP 403,响应体 {"code":"PA_UNAUTHORIZED_RESULT_FROM_POLICIES","blocked_by":"PolicyAgent","message":"At least one policy returned UNAUTHORIZED."}
  • /sites/MLA/search?q=iphone&limit=1 — HTTP 403,{"message":"forbidden","error":"forbidden"}
  • /items/{id} — HTTP 403,同样是 PolicyAgent

而且问题不仅在于缺少令牌。卖家和集成商在公共投诉中描述了相同的情况,即使有有效的访问令牌:/users/me 和订单正常响应,而目录和评级端点返回 blocked_by: PolicyAgent。API 的访问政策正在逐步收紧,针对特定端点,而文档未能跟上。

与此同时,平台对仍然依赖官方 API 的用户有两个技术截止日期:

  • 自 2026 年 8 月 30 日起,应用程序必须分开:一个用于 Mercado Libre,另一个用于 Mercado Pago。通过 GET applications/$APP_ID 进行检查——如果在权限范围中仍然存在 urn:mp:... 类型的权限,则需要重新提交应用程序,否则将失去对 Mercado Libre API 的访问;
  • 在查询参数中传递访问令牌被认为是不安全的:平台将开始拒绝此类请求,返回 301 响应。令牌必须仅在 Authorization: Bearer 头中发送。

实际结论很简单:2026 年的官方 API 是为使用自己账户的卖家提供的渠道,而不是市场分析工具。如果任务是监控竞争对手和区域价格,您需要使用公共展示。我们在文章中讨论了具体任务应选择什么 官方 API、现成数据集还是自定义解析器

七个展示而不是一个网站

Mercado Libre 不是一个带有国家过滤器的目录,而是一组独立的平台,拥有自己的域名、货币和商品报价。在 API 中,它们被称为 site_id

  • MLA — 阿根廷 (mercadolibre.com.ar, ARS)
  • MLB — 巴西 (mercadolivre.com.br, BRL)
  • MLM — 墨西哥 (mercadolibre.com.mx, MXN)
  • MLC — 智利,MCO — 哥伦比亚,MLU — 乌拉圭,MPE — 秘鲁,MLV — 委内瑞拉

在 MLA 和 MLB 中,同一商品是两张不同的卡片,两个不同的卖家,两个不同的物流方案。直接比较它们是毫无意义的:需要根据货币和送货条件进行规范化。顺便提一下,关于货币——平台自己提供了 HTML 中的格式化规则:对于阿根廷,"currency_id":"ARS""decimal_separator":",""thousands_separator":".""time_zone":"GMT-03:00"。使用正则表达式通过点切割价格的解析器在拉丁美洲的展示中会出错一千倍。

关键:价格和送货是根据收件人区域计算的

以下是直接嵌入在请求没有地址的结果页面 listado.mercadolibre.com.ar 中的片段:

"location_info":{"zipcode":"1430","inferred_zipcode":false,"default_zipcode":true,"user_zone":"X19"}

这可以理解为:邮政编码 1430,它并不是从您的 IP 推断出来的 (inferred_zipcode: false),它是默认的 (default_zipcode: true)。在页面顶部显示“Enviar a Capital Federal”——这意味着平台默默决定您在布宜诺斯艾利斯首都地区,并继续为该地区计算所有内容。

而它计算的内容很多。在同一 HTML 中,有与区域相关的送货标签:same_day_free_shipping,文本为“Llega gratis hoy”,图标 vpp_full_icon——“Enviado por FULL”(来自平台仓库的商品)。在请求“iphone”的结果页面中,免费送货的提及数量达到了 96 次。送货区域还影响 buy_box 中的“Outra opção de compra”:哪个卖家将赢得卡片,部分取决于谁能更便宜、更快地送到特定的邮政编码。

总结:一个从未指定送货区域的解析器收集到的不是“阿根廷市场”,而是一个城市的切片。对于距离首都一千公里的百万城市的国家报告来说,这是一个缺陷,虽然它不会立即显现——数字看起来很可信,只是它们并没有回答正确的问题。

入口的障碍:/gz/account-verification

第二个惊喜出现在传输层面。请求 listado.mercadolibre.com.ar/iphone 并不会立即返回结果:会收到HTTP 302 到 /gz/account-verification?go=...&tid=...——自己的设备验证页面。这不是 Cloudflare 也不是 DataDome:在屏障代码中没有 reCAPTCHA、Turnstile 或第三方反机器人标记,而是十几个对设备机制的调用。该页面约 41 KB,使用 JavaScript 构建,未执行脚本无法显示任何内容。

验证过程的行为非常具有代表性。第一次使用干净的服务器 IP 的请求通过了屏障:返回了真实的结果,大小为 2,425,906 字节——50 个 ui-search-layout 块和 120 个价格节点 andes-money-amount__fraction,所有内容均在服务器上渲染。来自同一地址的重复请求则被阻止在 /gz/account-verification,无法继续。来自同一 IP 的巴西和墨西哥展示则完全无法访问。

这是一种典型的“声誉”机制:地址获得少量的信任额度,经过几次请求后耗尽并关闭。单一测试并不能证明任何问题——重要的是,数据中心池没有稳定的访问,而行为因国家而异。

响应头中的另一个细节:平台设置了 _d2id(设备标识符,有效期为一年,重复出现在 x-request-device-id 中)和 _mldataSessionId,带有 Max-Age=1800。三十分钟就是会话的自然长度,应该根据这个来调整 IP 的保持。

robots.txt 的规定

在构建收集之前,值得阅读平台的规则。在两个展示(阿根廷和巴西)的 robots.txt 中,上面的块是相同的,并且非常明确:

  • 完全禁止 (Disallow: /) AI 爬虫:Amazonbot、GPTBot、ChatGPT-User、ClaudeBot、Claude-User、PerplexityBot、Perplexity-User;
  • 允许 社交媒体的预览爬虫:FacebookExternalHit、FacebookBot、Twitterbot、LinkedInBot;
  • 对于 Bingbot——Crawl-delay: 5 和一长串封闭的部分:/gz/cart//gz/checkout//perfil/vendedor//perfil/comprador//navigation//noindex/ 等等。

由此可以得出两个实际结论。第一:购物车、结账和用户资料显然是关闭的——无论是技术上还是法律上都不应访问。第二:Crawl-delay: 5 对于搜索爬虫来说是平台期望的速度的诚实指引。每个地址之间五秒的请求是合理的起点,而不是空穴来风的数字。

如何正确收集:操作顺序

  1. 固定收集矩阵。 不要使用“Mercado Libre”,而是使用“国家 × 送货区域”的配对列表。对于阿根廷,例如,Capital Federal、Córdoba、Rosario、Mendoza;对于巴西——São Paulo、Rio、Belo Horizonte、Recife。未指定区域的价格没有意义,这一决定在第一行代码之前就应作出。
  2. 获取所需国家的居民 IP。 在巴西和墨西哥展示上的服务器地址完全无法通过屏障,而在阿根廷展示上的请求在第一次后也被阻止。当地的住宅地址解决了访问和真实性的问题:平台最初向您展示的内容与当地买家看到的内容相同。
  3. 保持 IP 整个会话期间有效。 会话 cookie 的有效期为 30 分钟——每次请求的轮换会重置它和选择的区域,您将再次获得默认的邮政编码。对于一个区域保持 10-30 分钟的粘性会话,然后再更换。关于如何选择窗口长度,我们在 粘性会话 的指南中进行了讨论。
  4. 使用浏览器引擎,而不是裸 HTTP 客户端。 页面 /gz/account-verification 完全基于 JavaScript 构建:不执行脚本您将永远停留在屏障上。使用 Playwright 或类似工具,在步骤之间保持状态。
  5. 明确指定送货区域。 链接指向 /addresses/v3/navigation/hub;在设置地址后,状态保存在会话 cookie 中。每个会话只需运行一次此过程,而不是每张卡片。
  6. location_info 作为校验和。 在每个保存的页面上检查 zipcode 是否与目标一致,default_zipcode 是否变为 false。如果标志仍为 true——则不将该行写入数据展示,因为它不是为该区域收集的。仅此检查就能排除大部分静默缺陷。
  7. 从服务器 HTML 中提取价格。 价格和送货标签已经在服务器上渲染——无需追逐内部 JSON 端点。将 zipcodeuser_zonecurrency_id 和时间戳与价格一起存储:没有它们,数字无法验证。
  8. 保持速度。 平台的指引是每个地址之间五秒。需要速度——扩展地址池,而不是增加单个 IP 的请求频率:正是来自单个地址的激增会关闭屏障。

潜在的陷阱,迟早会发现

默认区域的静默缺陷。 最昂贵的错误不会通过异常抛出。数据被收集,报告被构建,定价决策被做出——直到一个季度后才发现,整个巴西的分析描述的只是圣保罗的一个区域。

页面重量。 一页结果为 2.4 MB。每天在四个国家和四个区域收集一千页——这每月会消耗数十 GB 的流量。在居民收费按流量计费的情况下,这是主要开支,因此最好立即在浏览器引擎中禁用图像和字体的加载:价格在 HTML 中,解析器的图片则是纯粹的浪费。

没有规范化的国家比较。 ARS、BRL、MXN 和不同的分隔符。根据收集日期的汇率将其转换为同一货币,并单独存储原始价格和货币,否则事后再计算将无法实现。

依赖官方 API。 如果集成仍然基于 API,请记住自 2026 年 8 月 30 日起对分开应用程序的要求,以及将令牌从查询参数移至头部。失去对 API 的访问看起来与您代码中的错误完全相同。

此任务需要什么类型的代理

居民代理——用于收集价格和送货的有效选择。需要您正在抓取的展示所在国家的地址,并且最好是您正在检查送货区域的那个地区:这样数据既能被提取,又能保持真实。居民代理 通过保持会话同时满足这两个要求。

移动代理——在特别顽固的屏障下使用。拉丁美洲是一个移动流量占比高的地区,移动运营商的地址对平台来说显得非常普通。在狭窄但关键的切片上是合理的,而不是在大规模的抓取中。

数据中心代理——用于侦查和服务任务:读取 robots.txt、提取页面结构、检查域名的可用性。对于定期收集价格,正如检查所示,资源是不够的。

总结

在 2026 年,Mercado Libre 不再提供匿名数据。官方 API 被 PolicyAgent 的政策关闭,展示页面会进行设备验证,而主要数字——价格和送货——是根据收件人区域计算的,如果不指定,平台会默认提供。正确的解析器与错误的解析器之间的区别不在于绕过的技巧,而在于纪律:国家、区域、货币和 location_info 应与每一行数据相邻。其他一切都是您请求来源的问题。