Booking.com 是酒店数据的经典硬目标——JS 渲染的价格、地域个性化，以及严肃的反爬。下面讲清价格如何运作，以及如何干净地采集它。
Booking.com 的价格是由 JavaScript 渲染且按地域个性化的，所以要用真实浏览器在目标国家的住宅或移动 IP 上采集它们——从数据中心 IP 做裸 HTTP 抓取只会返回陈旧、不具代表性的标记，并很快被封。设置正确的币种/区域、像人一样控制请求节奏，并按市场分别采集，因为同一间房本就会因国家而合理变动。请先审阅条款与法律。
Booking.com 上有用的信号是：按日期与入住人数划分的房价、可用性/库存、取消条款，以及它们随时间的变化——这些是价格一致性核查（我的酒店在各渠道定价是否一致？）、竞品对标与需求预测的原始素材。这些都不在初始 HTML 里；它们在页面加载后通过可用性调用送达。
这意味着可靠做法是用一个真实浏览器引擎来执行这些调用（或用有效会话忠实地重放它们），并在网站信任的 IP 上到达。在数据中心 IP 上，请求在价格渲染之前就被判定了——参阅 IP 信誉指南。
| 层 | 该怎么做 |
|---|---|
| 客户端 | 真实浏览器引擎（执行 JS 与可用性调用） |
| IP | 目标国家的住宅/移动 IP，而非数据中心 |
| 区域设置 | 设置币种 + 语言以匹配你采样的市场 |
| 节奏 | 类人的时间间隔与抖动；尊重速率限制 |
| 覆盖面 | 分别采样每个国家——价格因市场而异 |
为何按国家分别采样至关重要，详见：旅行地理定价 →
Booking.com 通过 JavaScript 与实时可用性调用渲染搜索结果与房价，这些调用绑定你的日期、入住人数、币种与检测到的位置。对 URL 做裸 HTTP 抓取只会返回不含真实当前价格的标记——你需要一个能执行页面的浏览器，或用正确的会话与请求头复现底层的可用性请求。
因为 Booking.com 按国家、币种、设备与会员（Genius）等级进行个性化。如果你的脚本从另一个国家的数据中心 IP 发起查询，看到的会是不同的——而且往往不具代表性的——价格。要捕获某个市场中真实顾客所见的价格，请从位于该市场的住宅或移动 IP 发起查询。
数据中心 IP 加上无头自动化指纹是最快被封的组合——IP 一眼被标记，客户端也不像真实浏览器。再加上快速、无规律的请求突发，你会立刻被挑战。受信任的本地 IP、真实浏览器与类人的节奏，才是保持采集稳定的关键。