几个月前，Stack Overflow 上一位开发者发了个问题，这个帖子从 2012 年一直挂到现在：“Google Places API Place Details 只能返回 5 条评论？” 十四年过去，几百个赞，答案还是一样——是的，最多 5 条评论。光是这一条限制，就足以说明这场争论为什么一直存在。
如果你曾经需要大规模获取 Google Places 数据——比如线索名单、竞品评论、客流趋势、本地 SEO 审核——你大概率也遇到过同样的分岔口。官方的 Google Places API 干净、结构化、文档完善；但它并不会返回你在 Google Maps 页面上能看到的全部内容，而且一旦超出免费额度，账单可能会非常夸张。抓取能拿到更多内容，成本结构也不一样，但它也有自己的麻烦（验证码、选择器失效、法律灰区）。我花了不少时间研究这两条路——API 文档、价格 SKU、抓取工具链，以及真实世界里的取舍——这篇文章就是这些调研的结果。我们会拆开讲字段缺口、10K/100K/1M 记录下的真实成本、反爬现实，以及一个实用的混合方案。最后还会给你一张决策流程图，毕竟没人想读完 3000 字后还是不知道该选什么。
什么是 Google Places API（它到底能给你什么）？
Google Places API 是 Google 官方提供的一种结构化方式，用来从它们的数据库里拉取商家数据——名称、地址、电话号码、评分、评论、照片等等。你发起一个 HTTP 请求，就能拿到格式化好的 JSON。这是官方认可的通道。
当前版本（Places API “New”）围绕 字段掩码（field masks） 来组织所有内容。调用 Place Details 时，你必须明确指定想要哪些字段——例如 displayName、formattedAddress、rating、reviews、photos 等——Google 会按你请求的最高等级字段来计费。若不提供字段掩码，系统不会返回默认结果，而是直接报错。这样设计的目的很明确：Google 希望你只为自己用到的内容付费（而且越“值钱”的字段，越贵）。
可用字段 按照不同价格层级划分：
| 层级 | 示例字段 | 你能拿到什么 |
|---|---|---|
| Essentials | Place ID、格式化地址、位置、照片元数据 | 基础身份信息和位置信息 |
| Pro | 展示名称、商家状态、Google Maps URI、主要类型 | 更丰富的商家信息 |
| Enterprise | 评分、评分人数、网站、电话号码、营业时间、价格等级 | 大多数业务用户真正想要的字段 |
| Enterprise + Atmosphere | 评论、评论摘要、生成式摘要、设施信息、停车、外卖/配送 | 最丰富、也最贵的数据 |
用户最常用的核心接口包括：Autocomplete（输入时搜索）、Text Search 和 Nearby Search（发现地点）、Place Details（补全已有地点信息）以及 Place Photos（获取图片）。
但真正重要的限制有这些：
- 评论： Place resource 每个地点最多只返回 5 条评论，而且是按相关性排序。就这么多。不是 50 条，也不是“全部”。只有 5 条。
- 照片： Place resource 中每个地点最多只有 10 条照片引用。
- 热门时段 / 实时拥挤度： 不是标准 Places API 字段。Google 确认这类数据存在 于面向消费者的界面中（基于聚合、匿名化的位置历史），而且它们的 Maps 博客也解释了 其工作方式——但 字段列表 里并没有它。
- Q&A 问答区： 不对外暴露。
- “用户还搜索了”竞争对手推荐： 不对外暴露。
- 菜单 / 价目表： 不是标准字段。
谁通常会用 Google Places API？
- 物流公司：验证地址并进行地理编码
- 旅游和酒店类应用：展示附近酒店、餐厅和景点
- 房地产平台：用本地商家数据丰富房源信息
- 本地 SEO 机构：检查 NAP（名称、地址、电话）一致性
- 销售团队：基于 Place ID 和基础商家信息生成线索名单
如果你的需求很明确，属于“我要在生产应用里拿结构化地点数据”，那 API 就是正确起点。如果你的需求里出现了“全部评论”“热门时段”或“竞品分析”这些词，那就继续往下看。
“抓取” Google Places 数据是什么意思？
网页爬虫 指的是用软件自动从网页中提取数据——这里指的是 Google Maps 或 Google 搜索结果页——而不是通过官方 API。爬虫会像浏览器一样读取页面，然后把页面上结构化的信息提取出来：商家名称、地址、评论文本、星级评分、热门时段直方图、Q&A、竞品推荐、完整图片库，以及页面上可见的其他内容。
关键区别在于：API 提供的是 Google 决定公开给你的内容；抓取则是理论上把人眼能看到的页面内容都拿出来。
不过，“抓取”并不是一种固定的方法。它有三种差异很大的路线，而它们之间的取舍也非常不一样。
自己写脚本 vs 托管抓取 API vs 无代码工具
| 方案 | 工作方式 | 最适合谁 | 主要取舍 |
|---|---|---|---|
| 自己写脚本（Puppeteer、Playwright、Selenium） | 你自己编写并维护无头浏览器脚本，访问 Google Maps 页面并解析 DOM | 需要完全控制权和自定义逻辑的开发者 | 维护成本最高——Google 一改界面，选择器就可能失效 |
| 托管抓取 API（Thunderbit API、SerpApi、Outscraper） | 你把 URL 或查询发给 API；它负责渲染、反爬处理和解析，并返回结构化数据 | 想要结构化结果、但不想自己维护爬虫的开发者 | 不同厂商的定价和质量差异大，本质上是在信任第三方 |
| 无代码浏览器扩展（Thunderbit Chrome Extension） | 在浏览器里点选提取——AI 推荐字段，你点击“Scrape”，再导出到 Sheets/Excel | 需要快速把数据弄进表格的业务人员、市场人员、销售团队 | 对复杂流程的灵活性较弱；效果依赖工具的 AI 质量 |
一句话总结：自己写脚本 = 最灵活，但维护最麻烦。托管 API = 有结构化输出，但不用自己维护。无代码工具 = 非开发者最快上手。
Google Places API vs 抓取：逐字段对比
这是我做这个调研时最希望一开始就能看到的表。业务用户和开发者可能需要的每个字段，这里都放在一起对比了：
| 数据字段 | Google Places API | 网页爬虫 |
|---|---|---|
| 商家名称 | ✅ 完整（Pro 层级） | ✅ 完整 |
| 地址 / 位置 | ✅ 完整（Essentials 层级） | ✅ 完整 |
| 电话号码 | ✅ Enterprise 层级 | ✅ 页面可见时可提取 |
| 网站 URL | ✅ Enterprise 层级 | ✅ 页面可见时可提取 |
| 综合评分 | ✅ Enterprise 层级 | ✅ 完整 |
| 评分人数 | ✅ Enterprise 层级 | ✅ 完整 |
| 单条评论（文本 + 评分） | ⚠️ 最多 5 条评论 | ✅ 可提取全部可见评论 |
| 热门时段 / 实时拥挤度 | ❌ 不是标准 API 字段 | ✅ 页面渲染后可提取 |
| Q&A 问答区 | ❌ 不对外暴露 | ✅ 可提取 |
| 照片元数据 | ✅ 通过 Photos 接口最多 10 条引用 | ✅ 完整图库 |
| 菜单 / 价目表 | ❌ 不是标准字段 | ⚠️ 页面存在时可提取 |
| “用户还搜索了”（竞品） | ❌ 不对外暴露 | ✅ 可提取 |
| 营业时间 | ✅ Enterprise 层级 | ✅ 页面可见时可提取 |
| 价格等级 | ✅ Enterprise 层级 | ✅ 页面可见时可提取 |
| Place ID | ✅ 很强（Essentials） | ⚠️ 可以获取，但 API 才是权威来源 |
| Google Maps URI | ✅ Pro 层级 | ✅ 就是页面 URL |
| 店主对评论的回复 | ⚠️ 需确认当前可用性 | ✅ 通常可见 |
| SERP / 地图包位置 | ❌ 不是 API 的用途 | ✅ 通过 SERP 抓取可得 |
最关键的缺口是：如果你需要完整评论集合来做情感分析、口碑监测或竞品对标，单靠 API 根本不够。每个地点 5 条评论只是样本，不是数据集。
热门时段和客流模式也是同样的情况。如果你是零售顾问或商业地产分析师，抓取是唯一的路径——因为这类数据根本不在 API 里。
反过来，如果你需要的是权威的 Place ID、用于地理编码的结构化地址，或者要做店铺定位器，API 会更干净、更稳定，也更官方。
真正的成本：Google Places API vs 抓取，在 10K、100K、1M 记录下要花多少钱
成本是这个决策里最容易被误解的部分。很多人先用 API 的免费额度做个原型，等规模一上来，账单就会让人倒吸一口凉气。反过来，在抓取这边，很多人又低估了代理成本和开发时间。
所以我们来算一算。
Google Places API 定价拆解
Google 在 2025 年 3 月重做了 Maps Platform 定价，用 SKU 级免费额度和按量阶梯取代了原来的每月 $200 固定赠金。当前定价 大致如下：
- Essentials 字段（Place Details）：每月 10,000 次免费请求，之后每 1,000 次 $5.00，直到 100K
- Pro 字段（Place Details）：每月 5,000 次免费，之后每 1K $7.00
- Enterprise 字段（Place Details）：每月 1,000 次免费，之后每 1K $20.00
- Enterprise + Atmosphere（评论、设施等）：每月 1,000 次免费，之后每 1K $25.00
一个关键细节：如果你的字段掩码里包含哪怕一个 Enterprise + Atmosphere 字段（比如 reviews），整个请求都会按这个层级计费。而典型流程往往会串联多个 SKU——先用 Text Search Pro 找地点，再用 Place Details Enterprise + Atmosphere 补全信息——所以费用会叠加。
一次“查询”往往不止一笔可计费请求。
抓取成本：工具、代理和开发时间
抓取成本主要分成三块：
- 工具订阅或 API 点数：托管抓取 API 通常按请求、按点数或按记录收费。SerpApi 是按搜索计费。Outscraper 则是按记录付费。Thunderbit 的 API 使用点数体系（Extract = 每次请求 20 点）。Thunderbit Chrome Extension 则是每输出一行消耗 1 个点数。
- 代理费用（仅 DIY 方案）：抓取 Google Maps 的住宅代理通常每月 $50–$300，具体取决于流量和供应商。
- 开发时间（仅 DIY 方案）：构建和维护 Puppeteer/Playwright 脚本。这是最容易被忽略、但最会拖垮 DIY 经济性的隐性成本（下面会展开）。
API vs 抓取：规模化成本对照表
| 规模 | Google Places API（Enterprise + Atmosphere） | 托管抓取 API（估算） | DIY 抓取（代理 + 开发时间） |
|---|---|---|---|
| 每月 10K 条记录 | 约 ~$225（1K 免费，9K × $25/1K） | 约 ~$50–$150，视厂商而定 | 约 ~$50 代理费 + 每月 2–4 小时开发维护 |
| 每月 100K 条记录 | 约 ~$2,475（超过免费额度后按阶梯计费） | 约 ~$250–$500 | 约 ~$150 代理费 + 每月 8–16 小时开发维护 |
| 每月 1M 条记录 | 约 ~$17,975（按量阶梯会降低单价，但总额仍很高） | 约 ~$1,500–$3,000 | 约 ~$300 代理费 + 每月 20+ 小时开发维护 + 失效风险 |
说明：API 估算基于 Google 公布的阶梯价，适用于 Place Details Enterprise + Atmosphere，并在 1K 免费额度之后计算。托管抓取 API 的估算为不同厂商的大致区间。DIY 开发时间按 $50–$100/小时的综合成本计算。
结论很清楚：在小规模（10K 以下）时，如果你只需要 Essentials 或 Pro 字段，API 的免费额度往往让它成为最便宜的选择。到了业务规模（100K 以上），API 成本会迅速上升，尤其是富字段。到了企业规模（1M+），API 每月可能接近五位数，而抓取或数据服务在经济上会更有吸引力——前提是你确实需要那些 API 不提供的额外字段。
如果你只需要地址和 Place ID，就别抓取。对于这类需求，API 更便宜，也更合适。抓取的成本优势，只在你需要 API 无法返回的数据时才成立。
反爬现实：为什么 DIY Google 爬虫总会坏
这部分是抓取拥护者经常略过的。Google 不希望你抓 Google Maps，所以它们搭了好几层防线，而且会持续更新。
Google 的多层防护
- reCAPTCHA 挑战：自动化浏览器触发验证码的概率远高于真人用户
- 客户端 JavaScript 渲染：Google Maps 是一个重度 JavaScript 应用。普通 HTTP 请求拿不到渲染后的内容——你必须用完整的无头浏览器
- 浏览器指纹识别：Google 会通过 canvas 指纹、WebGL、navigator 属性以及其他信号识别无头浏览器
- IP 限流：同一个 IP（或同一个代理网段）请求过多就会被封
- DOM 结构变化：Google 会频繁调整页面结构——Reddit 和 GitHub issue 里的普遍共识是，选择器通常每隔几周到几个月就会失效
最后这一点最致命。一个在 6 月跑得很完美的 Puppeteer 脚本，到了 7 月可能就全空了，只因为 Google 改了一个 CSS 类名，或者重构了某个 div。
维护 DIY 脚本的隐性成本
每次 Google 改 DOM，你团队里总得有人去做这些事：
- 先发现爬虫挂了（最好是在坏数据扩散之前）
- 检查新的页面结构
- 更新选择器、处理新的验证码类型、调整重试逻辑
- 测试并重新部署
拉长到一年，这部分维护时间很容易超过托管抓取 API 的订阅费。我见过有团队每年为了让 Google Maps 爬虫继续活着，烧掉 40 多个开发工时——而这还是在一个中等复杂度环境下的保守估计。
为什么会有托管抓取 API
正是因为这种维护负担，才会有像 Thunderbit 的 API、SerpApi 和 Outscraper 这样的服务存在。它们把反爬复杂度——JavaScript 渲染、验证码处理、代理轮换、选择器维护——都接过去，然后直接返回结构化数据。
Thunderbit 的 POST /extract 接口配合 renderMode: "full"，可以处理像 Google Maps 这种重度 JavaScript 页面，并返回与 schema 匹配的结构化 JSON，而不是还得继续解析的原始 HTML。 MCP server 则把这件事扩展到了 AI Agent 场景——Claude、Cursor 或其他基于 LLM 的工作流，可以在任务中途直接抓取 Google Maps 数据，而不用离开当前环境。
对非技术用户来说，Thunderbit Chrome Extension 是“零维护”方案：打开 Google Maps 页面，点“AI Suggest Fields”，点“Scrape”，导出到 Sheets。不要选择器，不要代理，不要调试。
SerpApi 和 Outscraper 也是不错的替代方案，只是定价模型和输出格式不同。SerpApi 会按每次搜索返回结构化 JSON；Outscraper 按记录收费，采用即用即付。具体选谁，取决于你的数据量、预算，以及你是需要结构化 JSON，还是能接受半结构化输出再自己处理。
混合打法：把 Google Places API 和抓取一起用
关于这个话题，很多排名靠前的文章都没提到一个我在实践中见过最有效的做法：两个都用。很多团队最后都会把官方 API 用在一部分任务上，把抓取用在另一部分任务上。关键是给每种工具找对活。
什么时候官方 API 更强
- 实时生产应用里的 Autocomplete：低延迟、符合 ToS、稳定 SLA。没得比。
- 基于位置的应用后端：店铺定位器、地址验证、Place ID 匹配。API 结构化、受支持、文档齐全。
- 对合规特别敏感的集成：企业合同、面向公众的产品，或者任何不能在 Google ToS 上冒风险的场景。
什么时候抓取更强
- 完整评论提取（每个地点 5K+ 评论）：情感分析、口碑监控、竞品对标。API 的 5 条上限在这里几乎没用。
- 一次性线索名单提取：没有持续账单的批处理任务会更便宜。像 Thunderbit 这样的无代码工具 可以在几分钟内抓一批商家并导出到表格。
- 热门时段 / 客流分析： API 不提供。就是这样。
- Q&A 数据、竞品“用户还搜索了”：只在页面上可见，不在 API 中。
什么时候适合混合方案
- 持续的价格 / 评分监控：API 用来拿基础结构化数据（Place ID、地址、综合评分），再抓取 API 里没有的深度字段（完整评论、热门时段）。
- 数据补全流程：先用 API 获取 Place ID 和权威商家信息，再抓取单个详情页拿完整评论、Q&A 和竞品上下文。
- 定时监控：无代码用户可以用 Thunderbit 的定时爬虫；开发者可以用 CLI 批量抽取并通过 cron 跑定时任务，无需自建复杂基础设施。
用例决策矩阵
| 用例 | 推荐方式 | 原因 |
|---|---|---|
| 生产应用里的 Autocomplete | ✅ 官方 API | 低延迟、符合 ToS、稳定 |
| 拉取 5K+ 完整评论集 | ✅ 抓取 / 抓取 API | API 每个地点最多 5 条评论 |
| 一次性本地商家线索名单 | ✅ 抓取（或 Thunderbit 扩展） | 批量处理更便宜，没有持续账单 |
| 热门时段 / 客流分析 | ✅ 只能抓取 | API 不提供 |
| 持续价格 / 评分监控 | ⚠️ 混合方案 | API 管基础数据，抓取补深度字段 |
| 基于位置的应用后端 | ✅ 官方 API | 结构化、受支持、SLA 明确 |
| 本地 SEO 的 SERP 排名追踪 | ✅ 抓取 / SERP API | 这不是 Places API 的用途 |
| 竞品“用户还搜索了” | ✅ 只能抓取 | API 不暴露 |
决策流程图：Google Places API vs 抓取，你到底该选哪个？
与其说“要看情况”，不如直接给你一个清晰的判断框架。按下面四个问题一步步走：
1. 你是否需要在生产应用中使用实时数据？ → 是：用官方 API。它受支持、有 SLA，而且符合 ToS。到此为止。 → 否：继续。
2. 你是否需要 API 不返回的数据（完整评论、热门时段、Q&A）？ → 是：必须抓取。API 根本给不了这些数据。 → 否：继续。
3. 你每月大概要处理多少条记录？ → 低于 10K：API 很可能是最便宜的，尤其是你只需要 Essentials 或 Pro 字段时。这个规模下免费额度很有用。 → 高于 10K：抓取或托管抓取 API 往往更划算，尤其是富字段场景。
4. 你有没有开发资源去搭建和维护爬虫？ → 有：用 Puppeteer/Playwright 自建，控制力最大（但记得预留持续维护成本）。 → 没有：用托管抓取 API（Thunderbit API、SerpApi、Outscraper）或无代码工具（Thunderbit Chrome Extension）。
面向开发者的替代方案速览
| 工具 | 计费方式 | 输出格式 | 能否处理反爬 | 支持批量 |
|---|---|---|---|---|
| Thunderbit API / MCP | 点数制（Extract = 每次请求 20 点） | 与 schema 匹配的结构化 JSON | ✅ 支持 JS 渲染、代理轮换、地理路由 | ✅ 每批最多 100 个 URL |
| SerpApi | 按搜索计费（分层套餐） | 结构化 JSON | ✅ | ✅ 通过 API 参数支持 |
| Outscraper | 按记录计费（即用即付） | JSON / CSV | ✅ | ✅ 通过任务队列支持 |
| DIY（Puppeteer/Playwright） | 代理费 + 开发时间 | 原始 HTML（你自己解析） | ❌ 需要你自己处理 | ✅ 取决于你自己怎么做 |
Thunderbit API 的差异点在于：它会基于你定义的 JSON Schema 返回匹配结构的 JSON，而不是还要再解析的原始 HTML 或 Markdown。 如果你要把数据喂给 LLM 流水线，或者直接写入数据库，这能省掉大量后处理时间。
Thunderbit 在这里怎么发挥作用（给业务用户和开发者）
我们做 Thunderbit 的目的，就是把“我需要 Google Maps 数据”和“我不想变成爬虫基础设施工程师”这两件事之间的鸿沟补上。下面分别说说它对两类人怎么用。
对非技术用户：Chrome 扩展
- 打开一个 Google Maps 页面——可以是搜索结果页，也可以是单个商家详情页
- 点击 “AI Suggest Fields”——Thunderbit 的 AI 会读取页面并自动建议字段（商家名称、地址、评分、评论、电话等）
- 点击 “Scrape”——扩展会把数据提取成结构化表格。需要的话可以用云模式，同时跑最多 50 个页面
- 抓取子页面——点击 “Scrape Subpages”，逐个访问列表页，拉取完整详情
- 导出——到 Excel、Google Sheets、Airtable 或 Notion。数据导出免费，没有付费墙
如果你要做周期性监控——比如每周检查竞品评分、追踪新商家——定时爬虫可以按你设置的频率自动运行。
对开发者：API、MCP Server 和 CLI
- 带 JSON Schema 的
POST /extract：传入 Google Maps URL，定义你需要的字段，返回结构化 JSON。对于重度 JavaScript 页面，设置renderMode: "full"。 Thunderbit 会处理 渲染、反爬、代理轮换和地理路由。 POST /distill：从任意页面获取干净的 Markdown——适合需要原始内容而不是结构化字段的 LLM 流水线。每次请求 1 点，而不是 20 点。- MCP Server：AI Agent（例如 Claude、Cursor）可以在任务执行过程中直接抓取 Google Maps 数据。支持内容提炼、结构化抽取、字段建议，以及最多 100 个 URL 的批量任务。
- CLI：
thunderbit batch extract --file urls.txt --schema places.json，适合定时任务或接入 CI/CD 的抓取流程。
点数计费：Extract = 每次请求 20 点，Distill = 每次请求 1 点。API 点数是按请求计费，不是按行计费（而扩展版是 1 点 = 1 行输出）。最新方案请查看 Thunderbit Pricing。
法律与服务条款要注意什么
我尽量简短、只讲事实——不吓人，也不推销。
Google Places API 的条款很明确：Google 的服务专属条款 说明，Places API 内容可以在不使用 Google 地图的情况下使用，但不能和非 Google 地图一起使用。经纬度可缓存最长 连续 30 个自然日；Place ID 可以无限期保存。详情、照片和评论都要求标注来源。
抓取 Google Maps 可能违反 Google 的服务条款。执法方式不一——风险包括 IP 封禁、验证码墙，以及在极少数情况下的法律行动。托管抓取 API 通常会替用户承担一部分合规负担，但这并不等于法律保护伞。
如果你做的是面向终端用户的生产应用，官方 API 是更稳妥的选择。如果你做的是内部研究、批量分析和竞争情报，抓取在行业里很常见。商业流程还是建议你咨询自己的法律顾问。
如果是我，我会怎么选，为什么
把定价 SKU、字段列表、社区讨论和工具文档都看了一遍后，我的结论是：
- 用官方 API：当你需要在生产应用中获取实时、符合 ToS 的数据，或者 Essentials / Pro 字段已经够用，并且月处理量低于 10K 时。这个规模下免费额度很大，数据质量也最有保障。
- 用抓取（托管 API 或无代码工具）：当你需要完整评论、热门时段、Q&A、竞品上下文，或 API 根本不暴露的任何字段时。或者当你的月记录数超过 10K–100K，而且你还在请求富字段（Enterprise + Atmosphere）时——这时候 API 账单就很难说得过去了。
- 两个都用：当你的流程既需要权威 Place ID 和基础结构化数据（API），又需要页面上可见的深度情报（抓取）时。这种情况比大多数文章承认的要常见得多。
成本拐点很明确：在每月约 10K 条以下、且只用基础字段时，API 更简单，而且通常还是免费的。超过这个规模，尤其是富数据场景，抓取会更划算。到了 1M 条且使用 Enterprise + Atmosphere 字段时，API 大约要 ~$18K/月，而托管抓取只需要其中的一小部分。
如果你想自己试试，Thunderbit Chrome Extension 是最直接的方法，能让你立刻看到抓取能拿到什么，而 API 又能拿到什么。开发者流程可以看 Thunderbit API 文档，上手所需内容都在里面。如果你想进一步了解 无需编码的网页爬虫 或更广义的 AI 网页爬虫，我们博客里也有很多深入内容。
核心结论
- Google Places API 更适合生产应用、Autocomplete 和结构化地点查询——但它把评论上限设为 5 条、照片上限设为 10 条，并且不暴露热门时段、Q&A 或竞品推荐。
- 抓取可以拿到 Google Maps 页面上可见的一切，包括完整评论集和热门时段数据，但你需要自己应对反爬，或者为托管服务付费。
- 在每月 10K 条以下，API 的免费额度通常让它成为最便宜的方案。超过 100K，尤其是富数据场景，抓取或托管抓取 API 往往更经济。
- DIY 爬虫会因为 Google 的反爬防护和 DOM 变化频繁失效——要么预留每年 40+ 小时维护，要么直接用托管工具。
- 现实中最好的方案通常是混合式：API 负责权威 ID 和基础字段，抓取负责 API 给不了的深度信息。
- Thunderbit 同时覆盖两边：无代码用户用 Chrome 扩展，开发者用结构化 JSON 的 API / MCP Server。
常见问题
能不能通过 Places API 拿到 5 条以上的 Google 评论？
不能。Google Places API 每个地点最多返回 5 条评论，而且按相关性排序。自从这个 API 发布以来一直如此，尽管开发者多年来一直在提需求，也没有改变。想拿到某个商家的全部评论，只能抓取（自己做，或者通过托管抓取 API）。
抓取 Google Maps 合法吗？
没有一个放之四海而皆准的是或不是。抓取公开可见的 Google Maps 数据可能违反 Google 的服务条款，执行力度从 IP 封禁到极少数情况下的法律行动都有。很多企业会把抓取用于内部研究和竞争情报，而且并不会出问题。托管抓取 API 能帮你分担一部分合规风险，但它们不是法律保护伞。如果你要做商业产品，或者要处理个人数据，建议咨询法律顾问。
如果要查 100K 条记录，Google Places API 要多少钱？
这取决于你请求哪些字段。如果是 Place Details 的 Essentials 层级，大约 ~$450；Pro 层级约 ~$1,615；Enterprise + Atmosphere（包含评论和设施）约 ~$2,475。如果你的流程还需要用 Text Search Pro 做发现，那么还要再加大约 ~$3,040。这些估算基于 Google 公布的阶梯价，并假设每条记录在免费额度之后对应一次可计费请求。
抓取 API 和无代码抓取工具有什么区别？
抓取 API（比如 Thunderbit 的 Open API）是给开发者用的，方便通过 HTTP 请求把抓取接入代码、自动化流程或 AI Agent 工作流。无代码工具（比如 Thunderbit Chrome Extension）则允许非技术用户在浏览器里点点选选，不写代码就能导出数据。两者都能返回结构化数据，区别在于交互方式和集成方式。
Thunderbit 能处理 Google Maps 页面吗？
可以。Chrome 扩展可以抓取 Google Maps 搜索结果页和单个商家详情页——AI 会自动建议字段，而且云模式下最多可同时处理 50 个页面。API 的 POST /extract 接口配合 renderMode: "full" 可以处理 Google Maps 的 JavaScript 渲染页面，并返回与 schema 匹配的结构化 JSON。 MCP server 还能让 AI Agent 在工作流中途直接抓取 Google Maps 数据。
了解更多
