用途：把 Booking.com 的目的地搜索转成一张住宿房东/物业经理线索表，含真实联系方式。核心思路是瀑布式补全：先用最便宜的来源，仅对仍缺联系方式的线索才回退到更贵的来源，不要一上来就用 Google Maps 邮箱提取器。
主要能力与分层：第 1 层抓 Booking 的 traderInfo（邮箱、电话、公司），免费且已随抓取获得，覆盖因地区而异（欧盟、澳洲较强，亚洲渐增，美英较稀疏）；第 2 层用 lukaskrivka/google-maps-with-contact-details 按名称补邮箱、电话、社交和网站；第 3 层用 apify/google-search-scraper 找候选官网；第 4 层用 vdrmota/contact-info-scraper（默认，确定性、约 14 秒/站）或 apify/ai-web-scraper 从网站提取邮箱/电话/社交。
使用方式：需 Apify 账号，通过 apify login（OAuth）或 APIFY_TOKEN 环境变量认证。先收集目的地、物业类型、最大数量和输出格式，再依次调用各 Actor，最后输出每物业一行，报告总行数、有邮箱比例和 contactSource 分布。调用示例：apify actors call "voyager/booking-scraper" -i '{"search":"Melbourne","maxItems":50,"propertyType":"Apartments"}' --json --user-agent apify-awesome-skills/apify-booking-host-leads 2>/dev/null。也可用 Apify MCP 服务器（https://mcp.apify.com）。
输出字段：name、type、address、city、country、rating、ratingLabel、stars、reviews、BookingURL、email、phone、companyName、registrationNumber、traderAddress、hostName、managedProperties、website、socials、contactSource（booking-trader | google-maps | none）。邮箱和电话紧跟在地址之后。
限制：traderInfo 覆盖因地区而异，美英较稀疏；Google Maps 回退可能匹配到错误商家，应信任 booking-trader 行、把 google-maps 行视为低置信；仍无联系方式的线索可用 BookingURL 通过 Booking 消息联系。AI 网站抓取在实测中较慢且多站失败，优先用 contact-info-scraper。成本随层数上升，可跳过 Google Maps 回退，仅 traderInfo 约覆盖 80%。