# Google Places API alternative：千家地点实测比价 > 同样 1,000 个地点带评论，Google Places API 标价 $2–$25，免费额度内为 $0；我们实测 $1.42，每家 100 条评论。 - Canonical page: https://everyinfra.com/blog/google-places-api-alternative - Published: 2026-11-09T03:05:00+08:00 · Fact-checked: 2026-11-09T00:45:00+08:00 同样拿 1,000 个地点的详情和评论，Google Places API (New) 按 2026 年 11 月 3 日更新的价格表标价 $2.00 到 $25.00，取决于你走 Text Search 还是 Place Details；如果这是账户当月唯一的用量，1,000 个地点刚好落在免费额度里，Google 一分钱不收。我们在 2026 年 11 月 9 日用 EveryInfra 真调，同样 1,000 个地点（每次搜 50 家、每家调 1 次评论）是 $1.42，而且每家给 100 条评论，Google 每家最多 5 条。换句话说：要每家 5 条以上、或者按最新排序的评论，只有换过来才做得到；只要地点详情、每月超过约 2 万个地点，我们的单价约是 Google 的 1/63；带 5 条评论、每月不到约 6.9 万个地点，Google 更便宜。 > **本文要点** > > - Google Places API (New) 按字段遮罩里最贵的字段计费：只要带上 `reviews`，Place Details 就按每 1,000 次 $25 收，Text Search 按每 1,000 次 $40 收；每个 SKU 每月有 1,000 次免费。 > - 1,000 个地点带评论：Google Text Search 路线标价 $2.00、Place Details 路线 $25.00，免费额度内都是 $0；EveryInfra 实测 $1.42，每家最多 100 条评论，Google 每家最多 5 条。 > - 按免费额度算，带评论时每月约 68,585 个地点以下 Google 更便宜；只要地点详情不要评论时，约 20,323 个以上就是我们更便宜，到每月 10 万个地点时是 $2.78 对 $140。 > - 新加坡、芝加哥、马德里各 50 家医疗点，5 条上限只能看到全部评论的 0.62%–2.83%；我们一次调用能看到 11.59%–51.06%。 > - 本文 21 次请求里 13 次扣费，合计 $0.018057；401、422、空结果、坏链接都没扣钱。 这篇写给正在用 Google Places API、或者正在搜「google places api alternative」的开发者。站内已经有一篇[讲三条路怎么批量抓 Google 地图评论](/blog/how-to-scrape-google-maps-reviews)的长文，和一篇[给牙科诊所做 Google 点评竞品周报](/build/data-api-side-business-dental-review-brief)的实战；本篇不重复那两篇，只讲一件事：从 Google 官方的 Places API (New) 换过来，钱怎么算、字段怎么对、哪些情况不该换。Google 一侧我们只读公开文档、价格表和条款，2026 年 11 月 9 日 00:14–00:18（新加坡时间）逐页打开存档，没有用 Google 的 Key 调用；我们这一侧全部是同一天 00:19–00:30 的真调，文中每个数字都能回到原始返回。 ![示意插图：一条传送带上前后排着三道收费闸门，由小到大；一只小铁丝筐被送进最大的那道闸门，筐里装着几个灰色小盒子和一个发青绿色光的大盒子，因为这一个大盒子，整只筐都走最大的闸门，小闸门和中闸门空着；每道闸门旁边堆着硬币，最大闸门旁的硬币堆最高。](https://everyinfra.com/articles/google-places-api-alternative/img-explain.webp) 字段遮罩计费：一次请求里只要有一个字段属于最贵的那一档，整次请求就按那一档收钱。 ## 先看结论：google places api alternative 按用量怎么选 先把结论放前面。用 Places API 的人大致分三种：在自己的 App 里给用户显示地点信息的、批量拿地点和评论做分析的、给 AI agent 当地点工具的。三种人该选的不一样，下面这张表按「每月多少个地点、要不要评论」给出更便宜的一边，价格是 2026 年 11 月 9 日读到的 Google 公开价和我们的目录价，Google 一侧已经扣掉每月免费额度，并假设这是计费账户里唯一的用量。 | 你的用法 | Google 最便宜的取法 | Google 月账 | EveryInfra 月账 | 更便宜的一边 | | --- | --- | --- | --- | --- | | 每月 1,000 个地点，带最多 5 条评论 | Text Search 带 `reviews`，50 次请求 | $0 | $1.42 | Google | | 每月 1 万个地点，带最多 5 条评论 | Text Search 带 `reviews`，500 次请求 | $0 | $14.17 | Google | | 每月 10 万个地点，带评论 | Text Search 带 `reviews`，5,000 次请求 | $160.00 | $141.68 | EveryInfra | | 每月 100 万个地点，带评论 | Text Search 带 `reviews`，5 万次请求 | $1,960.00 | $1,416.78 | EveryInfra | | 每月 10 万个地点，只要评分、电话、网站 | Text Search Enterprise，5,000 次请求 | $140.00 | $2.78 | EveryInfra | | 每家要 100 条以上评论、按最新排序 | 做不到（每家最多 5 条，按相关度） | — | 每家 $0.001389 | 只有我们能做 | | 在 Google 地图上给用户看地点卡片 | Places UI Kit 或 Place Details | 视用量 | 不适用 | Google | 这张表的意思是：Google 的免费额度很实在，小用量和「显示给用户看」这两种场景，没有理由换。换过来真正省钱的是两种情况：一是你要的不是评论、只是一大批地点的评分和联系方式，这时我们每次 50 家、每 1,000 家 $0.0278，比 Google 便宜两个数量级；二是你要的评论不止 5 条，或者要按时间看最新的评论，这件事 Google 的接口按设计就做不到，不是多花钱能解决的。后面每一节都会把这张表里的数拆开算一遍。 ## Google Places API (New) 怎么计费：字段遮罩决定 SKU Places API (New) 的计费单位不是「一个地点」，而是「一次请求」，价格看你在 `X-Goog-FieldMask` 里要了哪些字段。Google 的 [SKU 说明页](https://developers.google.com/maps/billing-and-pricing/sku-details/places)写得很直接：字段遮罩里的字段如果来自几个 SKU，整次请求按其中最贵的那个 SKU 计费。比如你只想要店名和地址，但顺手加了一个 `rating`，这次请求就从 Pro 档跳到 Enterprise 档；再加一个 `reviews`，就跳到最贵的 Enterprise + Atmosphere 档。下面是我们 2026 年 11 月 9 日截下的原文，页面底部写着最后更新于 2026 年 11 月 4 日。 ![网页截图：Google for Developers 的 Places (New) SKU details 页面「Field mask billing」一节，青绿色框标出整段原文：Place Details、Nearby Search、Text Search 三个接口按字段遮罩里的字段计费；字段只来自一个 SKU 时按该 SKU 收费；来自多个 SKU 时按其中最贵的 SKU 收费，例如同时要 Essentials 和 Enterprise 的字段就按 Enterprise 收费。](https://everyinfra.com/articles/google-places-api-alternative/img-shot-fieldmask.webp) Google 原文：字段遮罩里有一个贵字段，整次请求就按贵的那一档收。2026-11-09 截图。 [Google for Developers 截图](https://developers.google.com/maps/billing-and-pricing/sku-details/places) 把这条规则和[价格表](https://developers.google.com/maps/billing-and-pricing/pricing)放在一起看，就知道评论为什么贵。[Place Details (New) 文档](https://developers.google.com/maps/documentation/places/web-service/place-details)专门有一段讲评分和评论：`rating` 和 `userRatingCount` 触发 Place Details Enterprise SKU；`reviews` 和 `reviewSummary` 触发 Place Details Enterprise + Atmosphere SKU，返回最多五条用户评论。Google 自己在那一段给的省钱建议是：如果你只需要星级和评论数，就别要 `reviews`，让请求停在 Enterprise 档。下表是本文要用到的几个 SKU，单位是每 1,000 次请求，取自价格表第一个用量档（免费额度之后到每月 10 万次）。 | SKU | 典型字段 | 每月免费 | 每 1,000 次 | 每次最多几个地点 | | --- | --- | --- | --- | --- | | Text Search Essentials (IDs Only) | `places.id`、`places.name` | 不限 | $0 | 20 | | Text Search Pro | 显示名、地址、坐标、类型 | 5,000 次 | $32.00 | 20 | | Text Search Enterprise | 评分、评论数、电话、网站、营业时间 | 1,000 次 | $35.00 | 20 | | Text Search Enterprise + Atmosphere | `reviews`、`reviewSummary` 等 | 1,000 次 | $40.00 | 20 | | Place Details Essentials (IDs Only) | `id`、照片元数据 | 不限 | $0 | 1 | | Place Details Pro | 显示名、营业状态、地图链接 | 5,000 次 | $17.00 | 1 | | Place Details Enterprise | 评分、电话、网站、营业时间 | 1,000 次 | $20.00 | 1 | | Place Details Enterprise + Atmosphere | `reviews`、`reviewSummary` 等 | 1,000 次 | $25.00 | 1 | | Place Details Photos | 地点照片 | 1,000 次 | $7.00 | 1 | 表里最后一列是本文后面所有计算的关键。Text Search (New) 一页最多 20 个地点：[Text Search 文档](https://developers.google.com/maps/documentation/places/web-service/text-search)写明 `pageSize` 不填时每页 20 条，填大于 20 也只回 20 条，一个查询翻页加起来最多 60 条。Place Details 一次只查一个地点。所以同样的 Enterprise + Atmosphere 档，Text Search 每 1,000 次 $40 换来最多 2 万个地点，Place Details 每 1,000 次 $25 只换来 1,000 个地点，按地点算前者便宜 12.5 倍。很多教程教的是「先搜出 place ID，再逐个查详情」，这条路在评论上是最贵的走法。 免费额度在 2025 年 3 月 1 日改过一次。Google 的[三月变更说明](https://developers.google.com/maps/billing-and-pricing/march-2025)写的是：原来每月 $200 的赠送额度取消，改为每个核心 SKU 每月固定一段免费用量，Essentials 档 1 万次、Pro 档 5,000 次、Enterprise 档 1,000 次。这段免费额度是按 SKU 算的，不是按项目算：同一个计费账户下所有项目加在一起，每个 SKU 每月共享这一段。Reddit 的 r/googlecloud 上有人问[「每月 1 万次免费是真的吗」](https://www.reddit.com/r/googlecloud/comments/1kzpdvo/new_to_google_maps_places_new_api_is_10k_requests/)，回帖的人也提醒，账单报表比用量面板晚几个小时，测试时最好先设硬上限。 ## 同样 1,000 个地点：Google 四种取法和我们的标价 把上一节的价格套到「1,000 个地点」上。Google 一侧有四种常见取法，我们一侧有三种组合，下表都按标价算、先不扣免费额度，这样才能看出用量大时的单价差。Google 的请求数按每页 20 个地点算；我们的搜索每次最多 50 家（目录 `max_limit` 是 50），评论每次最多 100 条。 | 取法 | 请求次数 | 标价 | 扣免费额度后 | 每家最多几条评论 | | --- | --- | --- | --- | --- | | Google：Text Search 只取 ID，再逐个 Place Details 带 `reviews` | 50 + 1,000 | $25.00 | $0 | 5 | | Google：逐个 Place Details，不带评论 | 1,000 | $20.00 | $0 | 0 | | Google：Text Search 字段遮罩带 `places.reviews` | 50 | $2.00 | $0 | 5 | | Google：Text Search Enterprise，不带评论 | 50 | $1.75 | $0 | 0 | | EveryInfra：`google_maps_reviews/search` 20 次 + `google_maps_reviews/reviews` 1,000 次 | 1,020 | $1.42 | 无免费额度 | 100（翻页最多 400） | | EveryInfra：再加每家 1 次 `google_maps_reviews/profile` | 2,020 | $2.81 | 无免费额度 | 100 | | EveryInfra：只要地点，`google_maps_reviews/search` 20 次 | 20 | $0.0278 | 无免费额度 | 0 | ![横向条形图，对数刻度：拿 1,000 个地点的标价。Google Place Details 带评论 $25.00，Place Details 不带评论 $20.00，Text Search 带评论 $2.00，Text Search 不带评论 $1.75，EveryInfra 搜索加每家一次评论 $1.42，EveryInfra 只要地点 $0.0278。](https://everyinfra.com/articles/google-places-api-alternative/fig-03-cost-1k-places-bar.zh.light.svg) 这张图要先看中间那两根柱子。很多人以为 Google 的评论贵在 $25，其实只要把 `places.reviews` 写进 Text Search 的字段遮罩，评论的单价就降到每 1,000 个地点 $2.00，和我们的 $1.42 是一个量级。差别在两处：第一，Google 这样做每家仍然只有 5 条评论，而且是按相关度挑的那 5 条，我们的 $1.42 里每家是 100 条；第二，Text Search 一个查询最多 60 个地点，要凑满 1,000 个地点至少要 17 个不同的查询词或位置组合，查询之间有重复时请求次数会更多，这一点我们的搜索也一样（一个查询最多 120 行，见后文）。 换成「每 1,000 条评论多少钱」看，三种取法差得更远。Place Details 路线每次 $0.025 换 5 条，合每 1,000 条评论 $5.00；Text Search 路线每次 $0.04 换 20 家 × 5 条，合每 1,000 条 $0.40；我们每次 $0.001389 换 100 条，合每 1,000 条 $0.0139，比 Google 最便宜的走法低约 29 倍。如果你只要地点详情、不要评论，Google 的 Text Search Enterprise 合每 1,000 家 $1.75，我们的 `google_maps_reviews/search` 合每 1,000 家 $0.0278，差约 63 倍。这两个倍数都是标价对标价，没算 Google 的免费额度，下一节把免费额度加进去。 ## 免费额度：每月多少个地点之内 Google 是 $0 只比单价对 Google 不公平，因为它每个 SKU 每月有一段免费额度，而我们没有。下面按「每月要多少个地点」算月账，Google 一侧扣掉免费额度、套用价格表的阶梯价（10 万次以上单价下降），假设这是计费账户里唯一的用量；我们一侧是目录价乘以调用次数。 | 每月地点数 | Google Text Search 带评论 | Google Place Details 带评论 | Google Text Search 不带评论 | EveryInfra 搜索 + 评论 | EveryInfra 只要地点 | | --- | --- | --- | --- | --- | --- | | 1,000 | $0 | $0 | $0 | $1.42 | $0.0278 | | 10,000 | $0 | $225.00 | $0 | $14.17 | $0.2778 | | 50,000 | $60.00 | $1,225.00 | $52.50 | $70.84 | $1.39 | | 100,000 | $160.00 | $2,475.00 | $140.00 | $141.68 | $2.78 | | 500,000 | $960.00 | $10,475.00 | $840.00 | $708.39 | $13.89 | | 1,000,000 | $1,960.00 | $17,975.00 | $1,715.00 | $1,416.78 | $27.78 | ![折线图，纵轴对数刻度：每月地点数从 1 千到 100 万时的月账。Google Text Search 带评论在 1 千、1 万时为 $0，5 万时 $60，10 万时 $160，100 万时 $1,960；Google Place Details 带评论 1 万时 $225，100 万时 $17,975；EveryInfra 搜索加评论从 $1.42 到 $1,416.78；EveryInfra 只要地点从 $0.0278 到 $27.78。](https://everyinfra.com/articles/google-places-api-alternative/fig-04-monthly-scale-line.zh.light.svg) 算出来的交叉点有两个。带评论时，Google 的 Text Search 路线前 1,000 次请求（也就是 2 万个地点）免费，之后每个地点 $0.002；我们每个地点 $0.0014168（1 次评论加 1/50 次搜索）。两条线在每月约 68,585 个地点处相交，低于这个量 Google 更便宜，高于这个量我们更便宜；到每月 100 万个地点时，Google $1,960、我们 $1,416.78。只要地点详情时，Google 的免费额度覆盖到每月约 2 万个地点，超过约 20,323 个之后我们更便宜，而且差距随用量拉大：每月 10 万个地点时 Google $140、我们 $2.78。 这一节有三个边界要说清。第一，Google 的免费额度是整个计费账户每个 SKU 共享的，如果你的账户同时在用 Place Details、地图加载、Autocomplete，免费额度会被分掉，交叉点会往左移。第二，我们没有每月免费额度，只有一次性的 $1 试用（给两个 GitHub 仓库点星后在控制台领取，24 小时内有效），所以每月用量很小的项目，用 Google 是对的。第三，表里的 Google 价是全球价格表；印度计费账户另有[印度价格表](https://developers.google.com/maps/billing-and-pricing/pricing-india)，Place Details Enterprise + Atmosphere 每月免费 7,000 次、之后每 1,000 次 $7.50，Text Search Enterprise + Atmosphere 每月免费 7,000 次、之后 $12.00，印度用户的交叉点要按那张表重算。 ## 5 条评论上限：在 150 家医疗点上意味着什么 Google 的 [Place 资源说明](https://developers.google.com/maps/documentation/places/web-service/reference/rest/v1/places)里，`reviews` 字段的原文是「关于这个地点的评论列表，按相关度排序，最多返回 5 条」。本篇要回答的是：在真实的一批地点上，5 条到底占全部评论的多少。我们在 2026 年 11 月 9 日 00:19–00:22（新加坡时间）搜了三个城市、三个公共卫生相关的品类，每个城市 50 家，用搜索结果里的 `review_count` 加总全部评论数，再按「每家最多 5 条」和「每家一次调用最多 100 条」分别算能看到多少。 | 城市和品类 | 地点数 | 评论总数 | 每家评论数中位 | 每家 5 条能看到 | 每家 1 次调用（100 条）能看到 | | --- | --- | --- | --- | --- | --- | | 新加坡 clinic | 50 | 25,368 | 146.5 | 235 条，0.93% | 3,689 条，14.54% | | 芝加哥 urgent care | 50 | 40,322 | 606.5 | 250 条，0.62% | 4,674 条，11.59% | | 马德里 farmacia | 50 | 8,833 | 137 | 250 条，2.83% | 4,510 条，51.06% | ![分组横向条形图：每个城市 50 家地点，一次请求能看到全部评论的比例。马德里药店 Google 每家 5 条为 2.83%，EveryInfra 每家一次调用为 51.06%；芝加哥急诊诊所 0.62% 对 11.59%；新加坡诊所 0.93% 对 14.54%。](https://everyinfra.com/articles/google-places-api-alternative/fig-05-review-share-bar.zh.light.svg) 三个城市里，芝加哥的急诊诊所评论最多，一家中位 606.5 条，最多的一家 3,235 条，5 条上限只能看到全部评论的 0.62%。马德里的药店评论少一些，一家中位 137 条，最多 463 条，所以每家调一次 100 条就能看到一半以上。新加坡的诊所介于两者之间。这个比例的意义在于：如果你要做的是「这一片区域的诊所口碑怎样」「哪家药店最近被投诉排队太久」这类分析，Google 给的 5 条连统计样本都谈不上，只能当展示用的摘要。 我们的评论接口也不是无限的。目录里写明 `google_maps_reviews/reviews` 每次最多 100 条，用 `page_token` 往下翻，同步最多翻到 200 条，用异步模式最多 400 条，每页算一次调用。所以一家有 3,235 条评论的诊所，我们最多能拿到最新的 400 条，约 12%；要全量的话，这个接口也做不到。对大多数分析来说，最近几百条比全量更有用，因为它反映的是现在的服务，而不是五年前的。 ## 实测一：新加坡诊所，一次搜 50 家 第一组实测在 2026 年 11 月 9 日 00:19:31（新加坡时间）发出，能力是 `google_maps_reviews/search`，参数 `keyword=clinic`、`location=Singapore`、`country=sg`、`limit=50`。10.06 秒后返回 50 行，50 个 `place_id` 全部不重复，扣费 $0.001389，和目录价一致。50 行里 47 行有评分、49 行有电话、41 行有网站、49 行有邮编，32 行的主分类是 Medical clinic，另有 Medical Center 3 行、Medical group 4 行，评分中位 4.4。 ```bash curl -s https://api.everyinfra.com/api/v1/social \ -H "Authorization: Bearer $EVERYINFRA_API_KEY" \ -H "Content-Type: application/json" \ -d '{"platform":"google_maps_reviews","action":"search", "params":{"keyword":"clinic","location":"Singapore","country":"sg","limit":50}}' ``` 这组数据里也有不干净的地方，照实写出来。排在第一行的是一家星象咨询，分类里挂了针灸和阿育吠陀诊所，地址却在印度金奈；还有 3 行（包括它）的坐标都是同一个点 1.352083, 103.819836，也就是新加坡的地理中心，说明这几家在地图上没有精确位置，接口回的是城市中心。另有一行是补习服务。用 `clinic` 这种泛词搜，结果会把「名字或分类里带 clinic」的地点都拉进来；做公共卫生分析时，要按 `category` 白名单过滤，并把坐标相同的行单独标出来。Google 的 Text Search 也是按相关度排的，会不会混进同样的噪音，我们没有用 Google 的 Key 实测，不下结论。 字段方面，搜索结果每行最多 19 个字段：`place_id`、`name`、`url`、`category`、`categories`、`address`、`city`、`state`、`postal_code`、`country_code`、`lat`、`lng`、`phone`、`website`、`rating`、`rating_scale`、`review_count`、`image_url`、`platform`。这些字段在 Google 一侧分属 Pro 档（名字、地址、坐标、类型）和 Enterprise 档（评分、评论数、电话、网站），同一个请求要全拿，就是 Text Search Enterprise 每 1,000 次 $35。我们这次 $0.001389 拿 50 行，等于每 1,000 家 $0.0278。 ## 实测二：芝加哥 urgent care，评论翻两页拿 200 条 第二组在芝加哥。00:21:48（新加坡时间）搜 `urgent care`，50 行全部在芝加哥市区范围内，47 行主分类是 Urgent care center，50 行都有电话和网站，扣费 $0.001389。评论最多的一家是 CLEAR Immediate Care，3,235 条评论、评分 4.6。00:23:27 我们用 `google_maps_reviews/profile` 查它的详情，13.68 秒返回 25 个字段，包括每周营业时间、街区、Plus Code、是否临时歇业，扣费 $0.001389。 00:24:24 用 `google_maps_reviews/reviews` 按最新排序取 100 条，5.45 秒返回 100 行，扣费 $0.001389；00:27:28 用上一页的 `next_page_token` 取第二页，6.97 秒又是 100 行，两页 200 条按评论 `id` 去重后仍是 200 条，没有重复。下面是第一页返回的截图，只留 2 条、评论正文截短、点评人名字隐去，青绿框标出返回条数和扣费。 ![接口返回截图：上半部分是请求体，google_maps_reviews 平台的 reviews 能力，参数是一家芝加哥急诊诊所的 Google 地图链接、sort 为 newest、limit 为 100；下半部分是返回，只留两条评论，一条 5 星一条 1 星，点评人名字已隐去，青绿色框标出 count 为 100、charged_usd 为 0.001389。](https://everyinfra.com/articles/google-places-api-alternative/img-shot-response.webp) 一次调用 100 条评论，扣 $0.001389；点评人名字已隐去。2026-11-09 00:24 新加坡时间。 [EveryInfra 接口真实返回截图](https://api.everyinfra.com/api/v1/social) ```text {"platform": "google_maps_reviews", "action": "reviews", "params": {"url": "https://www.google.com/maps/search/?api=1&query=CLEAR%20Immediate%20Care&query_place_id=ChIJLfMv0s0tDogRmyUtaRGOqlI", "sort": "newest", "limit": 100, "page_token": "<上一页的 next_page_token>"}} ``` 这 100 条最新评论里，1 星 25 条、2 星 3 条、3 星 2 条、4 星 2 条、5 星 68 条，平均 3.85 星，而这家店在地图上的总评分是 4.6。60 条有文字，10 条有商家回复，26 条来自本地向导。最新一条发于 2026 年 11 月 7 日。Google 的 Places API 对这家店最多只会给 5 条「最相关」的评论，你看不到「最近 100 个人里有 28 个打了 1–2 星」这个信号。第一页的排序也不是严格按时间，有几条更早的评论夹在中间，这一点站内[那篇评论抓取长文](/blog/how-to-scrape-google-maps-reviews)专门测过，处理办法是拿回来以后按 `posted_at` 自己重新排序。 ## 实测三：马德里药店，西语评论和空结果退款 第三组在马德里。00:22:05（新加坡时间）用 `language=es` 搜 `farmacia`，50 行的主分类全部是 Farmacia，49 行有电话、37 行有网站、评分中位 4.0，扣费 $0.001389。这组也有一行异常：一家网上药房没有地址，坐标落在北纬 35.67、西经 6.81，在摩洛哥境内，离马德里几百公里。按城市范围核一遍坐标，就能把它排除。 00:24:50 我们取了一家 24 小时药店（FARMACIA MAYOR 13，463 条评论，评分 3.7）的最新 100 条西语评论，参数 `lang=es`，12.81 秒返回 100 行。1–2 星 29 条、5 星 55 条，71 条有文字，32 条有药店回复，62 条来自本地向导，最新一条是 2026 年 10 月 31 日。00:25:10 又对另一家只有 39 条评论的小药店加了 `since=2026-11-08`，也就是只要前一天以后的评论：36.76 秒后返回 0 行，响应里写着 `refund.status: succeeded`，这次没有扣钱。 空结果不扣钱是我们和 Google 的一个明显区别。Google 的 SKU 说明里，每个 SKU 的计费事件写的是「成功的请求」，至于返回 0 个地点的请求算不算成功，原文没有写；而我们的目录和[价格页](/pricing)都写明失败或空结果不计费，这次实测也对上了。还有一个坏链接的测试：00:26:53 我们用一个不存在的 `query_place_id` 调评论接口，23.68 秒返回 0 行、`reason: empty_result_refunded`，同样没扣钱。 ## 100 条评论和 5 条讲的不一样 把三家店的 100 条评论按星级拆开，再和「按相关度排序的前 5 条」放在一起，能看出 Google 那 5 条的偏差方向。新加坡那家诊所我们按相关度取了 100 条：98 条 5 星、1 条 1 星、1 条 4 星，89 条有诊所回复，前 5 条全是 5 星。芝加哥和马德里按最新排序取的 100 条里，1–2 星分别占 28% 和 29%。 ![百分比堆叠横向条形图：同一家店 100 条评论的星级构成。芝加哥最新 100 条，1–2 星 28%，5 星 68%；马德里最新 100 条，1–2 星 29%，4 星 13%，5 星 55%；新加坡按相关度 100 条，5 星 98%；新加坡按相关度前 5 条，5 星 100%。](https://everyinfra.com/articles/google-places-api-alternative/fig-06-star-mix-bar.zh.light.svg) 这不能证明 Google 的相关度排序会故意挑好评，样本只有三家店，排序规则 Google 也没有公开。能说的是：按相关度排在前面的评论，通常是篇幅长、有人点赞、有商家回复的那些，在这家新加坡诊所上，它们恰好全是 5 星；而「最近有人在抱怨什么」只有按时间看才看得到。Places API (New) 的 `reviews` 只有相关度一种排序，不能改。旧版 Places API 的 Place Details 有一个 `reviews_sort=newest` 参数，[旧版文档](https://developers.google.com/maps/documentation/places/web-service/legacy/details)里还在，但上限同样是 5 条，而且旧版已经进入 Legacy 状态，新项目不建议再用。 ## 字段对照：Places API 的字段在我们这边叫什么 迁移最费时间的往往是字段名。下表左边是 Places API (New) 的字段（Text Search 里要加 `places.` 前缀），中间是它触发的 SKU，右边是我们对应的字段和能力。没有对应的照实写「没有」。 | Places API (New) 字段 | 触发的 SKU | EveryInfra 字段 | 在哪个能力里 | | --- | --- | --- | --- | | `id` | IDs Only（免费） | `place_id`（同一个 Google 地点 ID） | search、profile、reviews | | `displayName` | Pro | `name` | search、profile | | `formattedAddress` | Pro | `address`，另有 `city`、`state`、`postal_code`、`country_code` | search、profile | | `location` | Pro | `lat`、`lng` | search、profile | | `primaryType`、`types` | Pro | `category`、`categories` | search、profile | | `businessStatus` | Pro | `permanently_closed`、`temporarily_closed` | profile（search 只有前者） | | `googleMapsUri` | Pro | `url`（带 `query_place_id` 的地图链接） | search、profile | | `plusCode` | Pro | `plus_code` | profile | | `rating`、`userRatingCount` | Enterprise | `rating`、`review_count`、`rating_scale` | search、profile | | `nationalPhoneNumber`、`internationalPhoneNumber` | Enterprise | `phone`（一个字段，格式照地图上显示） | search、profile | | `websiteUri` | Enterprise | `website` | search、profile | | `regularOpeningHours` | Enterprise | `opening_hours`（按星期列时段原文） | profile | | `priceLevel`、`priceRange` | Enterprise | `price`（常为空） | search、profile | | `reviews[].text`、`originalText` | Enterprise + Atmosphere | `text`（原文，没有译文） | reviews | | `reviews[].rating`、`publishTime` | Enterprise + Atmosphere | `rating`、`posted_at` | reviews | | `reviews[].authorAttribution` | Enterprise + Atmosphere | `reviewer_name`、`reviewer_id`、`reviewer_review_count`、`is_local_guide` | reviews | | `reviews[].visitDate` | Enterprise + Atmosphere | 没有 | — | | 没有 | — | `owner_response`、`owner_response_at`（商家回复） | reviews | | 没有 | — | `like_count`、`image_urls`（评论附图） | reviews | | `reviewSummary`、`generativeSummary` | Enterprise + Atmosphere | 没有（AI 摘要要自己做） | — | | `photos` | Pro / Photos | `image_url`（一张封面图） | search、profile | | `paymentOptions`、`parkingOptions`、`servesBeer` 等设施字段 | Enterprise + Atmosphere | 没有 | — | 对照下来，我们这边有、Google 那边没有的主要是评论侧的字段：商家回复和回复时间、点评人的历史评论数、是否本地向导、点赞数、评论附图，这些对做口碑分析很有用。Google 那边有、我们没有的主要是三类：评论的机器翻译（`text` 和 `originalText` 分开）、到访月份 `visitDate`、Google 自己生成的评论摘要，以及一大批餐厅和停车、付款之类的设施字段。如果你的产品靠这些设施字段做筛选，比如「可带狗的户外座位餐厅」，Places API 仍然是更合适的数据来源。 ## 翻页和数量上限：60 条和 120 条 两边一个查询都拿不到无限多的地点。Google Text Search (New) 一个查询最多 60 个地点（3 页 × 20）；我们的 `google_maps_reviews/search` 目录写的是一个查询最多 120 行，同步调用最多到第 60 行，再往下要用异步模式。00:23:20（新加坡时间）我们用同步模式请求芝加哥搜索的第 2 页（第 51–100 行），0.12 秒就返回 422，错误码 `async_required`，提示改用 `"mode":"async"`，没有扣钱。00:29:41 改用异步提交，2.31 秒拿到 `job_id`，约 42 秒后（00:30:23）取到结果，取结果这一次只用了 0.15 秒、不扣钱，所以批量深翻页可以先一次提交一批任务，过一分钟再统一来取；第 2 页 50 行里只有 1 行和第 1 页重复，两页合计 99 家不重复的地点，第 2 页里 Urgent care center 的比例从第 1 页的 94% 降到 66%。 这说明两件事。第一，翻得越深，结果越偏离查询词，一个查询词翻到底的意义不大；要覆盖一个城市，更好的做法是换品类词、换街区或邮编多查几次，再按 `place_id` 去重，站内[讲 Place ID 去重的文章](/blog/google-maps-place-id-deduplication)写了怎么做连锁分店和搬迁记录。第二，异步提交那一刻就扣费（$0.001389），任务结果在 `GET /api/v1/jobs/{job_id}` 里取，查询结果不另外收钱；如果任务最后失败，会按同一笔记录退款。 ## 地点 ID 会变：两边都要定期刷新 迁移时很多人默认 place ID 是永久主键，这一点要先纠正。Google 的 [Place ID 文档](https://developers.google.com/maps/documentation/places/web-service/place-id)原文写着，同一个地点可能有多个不同的 place ID，place ID 也可能随时间变化：商家关门、搬到新地址，或者 Google 地图数据库更新，都可能让旧 ID 失效，这时用旧 ID 查询会得到 `NOT_FOUND`，地点本身可能已经换了一个新 ID。Google 的建议是超过 12 个月的 ID 刷新一次，刷新方法是发一次只要 `id` 字段的 Place Details 请求，走 Essentials IDs Only SKU，不收钱。 这件事对两边的影响不一样。在 Google 一侧，刷新 ID 是免费的，你可以每个月把库里所有 ID 过一遍，代价只是请求次数和配额。在我们这一侧，`place_id` 字段就是同一个 Google 地点 ID，我们没有单独的免费刷新接口；想确认一个 ID 还在不在，只能调一次 `google_maps_reviews/profile` 或评论接口。好消息是，ID 失效时我们不扣钱：本文 00:26:53 那次坏链接测试，传入一个不存在的 `query_place_id`，返回 0 行、`reason: empty_result_refunded`，扣费为 $0。坏消息是这次请求花了 23.68 秒才确认是空的。Google 一侧查失效 ID 要多久，我们没有实测，所以不做对比；只能说这种确认放在后台批量任务里没问题，放在用户正在等的页面上太慢。 所以我们建议的做法是：库里的地点主键继续用 Google 的 place ID，ID 刷新这一步留在 Google，用免费的 IDs Only 请求每季度或每月跑一次，把返回新 ID 的记录合并；评论和详情的批量拉取放在我们这边。连锁店分店、搬迁、同名不同店这几种情况怎样合并记录，站内 [Place ID 去重那篇](/blog/google-maps-place-id-deduplication)有完整的判断规则。还要记住一点：搜索结果里偶尔有坐标落在城市中心的行（新加坡那 3 行就是），这种行的 ID 是否更容易变，我们没有验证；建议入库时单独打一个标记，方便以后人工复核。 ## 失败、空结果和报错：哪些情况扣钱 这次 21 次请求里 13 次扣费、8 次 $0：7 次是下表里的报错或空结果，另 1 次是 00:30:23 用 `GET /api/v1/jobs/{job_id}` 取异步结果，它不算失败，不在表里。表里另加了一行扣了钱的乱码搜索作对照。时间都是 2026 年 11 月 9 日新加坡时间。 | 时间 | 情况 | HTTP | 我们返回什么 | 扣费 | | --- | --- | --- | --- | --- | | 00:19:17 | 不带 Key | 401 | 未鉴权，不回任何参数结构 | $0 | | 00:19:20 | 照搬 Google 参数 `textQuery`、`fieldMask`、`pageSize` | 422 | `missing_param`，提示要 `keyword`，并说明 `fieldMask` 不是这里的参数，附一个能跑的示例 | $0 | | 00:19:25 | 评论排序写成旧版的 `most_relevant` | 422 | `invalid_value`，列出允许值 newest、relevance，并猜你想写 relevance | $0 | | 00:22:23 | 搜索词是一串乱码加 clinic | 200 | 返回 20 家诊所（按 clinic 匹配），照常扣费 | $0.001389 | | 00:23:20 | 同步请求第 51–100 行 | 422 | `async_required` | $0 | | 00:25:10 | `since` 之后没有新评论 | 200 | 0 行，`refund.status: succeeded` | $0 | | 00:26:53 | 不存在的地点 ID | 200 | 0 行，`empty_result_refunded` | $0 | | 00:27:42 | 异步请求里 `limit=100` | 422 | `limit` 只能是 1–50 | $0 | 乱码那一行值得单独说：我们原本想用它测空结果，结果接口按其中的 `clinic` 匹配出 20 家真实诊所并照常扣费。也就是说，搜索词写错不一定得到空结果，不能靠「有没有返回」判断查询对不对，要看返回的 `name` 和 `category` 是否符合预期。Google 的 Text Search 同样是模糊匹配，原文对这种情况怎么计费没有单独说明，按「成功的请求」规则应当照常计费。 4 次 422 的返回里有两个字段，迁移时可以直接用上：`retryable` 和 `next_steps`。照搬 Google 参数那次，`next_steps` 原文让你补上 `keyword`，说明 `fieldMask` 不是这里的参数，并写明这次没有扣钱；排序写错那次还另带 `allowed` 和 `did_you_mean` 两个列表。4 次的 `retryable` 都是 `false`，也就是参数错了重发多少次都是 422。迁移脚本按这个字段决定要不要重试就行，参数错误不用写退避重试。 ![点图：每次调用的端到端耗时，单位秒。参数错误 422 共 4 次，中位 0.1 秒；地点搜索 4 次，中位约 10.3 秒；地点详情 3 次，中位 11.4 秒；评论 5 次，中位 6.6 秒；空结果退款 2 次，23.7 秒和 36.8 秒，中位 30.2 秒。](https://everyinfra.com/articles/google-places-api-alternative/fig-07-latency-dot.zh.light.svg) 耗时也照实说：搜索和详情一次 10–14 秒，评论 5–13 秒，空结果反而最慢（24 秒和 37 秒），因为接口要确认确实没有数据才会退款。Google 一侧的耗时我们没有测（本文没有用 Google 的 Key 调用），所以这里不做两边对比。只看我们自己的数：一次 5–14 秒，空结果 24–37 秒，适合后台批量任务，不适合放在用户点一下就要出结果的地方。 ## 防账单失控：预算提醒不会自动停 Places API 被抱怨最多的不是单价，而是账单失控。Reddit 的 r/webdevelopment 上有一篇[求助帖](https://www.reddit.com/r/webdevelopment/comments/1obolm0/please_help_i_got_a_bill_of_6k_using_google/)，标题写的是用 Places API 收到 $6k 账单，发帖人在回帖里说可能是代码进了死循环。回帖里有人说 Google 一般最多减免 50%；另一位列了四步：开账单工单；在 API 用量指标里找出是哪个接口暴涨，常见的是 Autocomplete 或 Place Details 被反复触发；立刻设每日配额和预算提醒；搜索框和前端加防抖和缓存。另一篇 r/webdev 的帖子在 2025 年 3 月改价前讨论[价格贵到做不成产品](https://www.reddit.com/r/webdev/comments/1gxqw6a/google_maps_places_api_pricing_not_to_beat_a_dead/)：发帖人说光开发测试就用掉了当时每月 $200 赠送额度里的 $75；回帖里有人说收到 Google 的改价邮件后，估算的新成本「难以承受」，改用了开放地图数据；也有人贴出条款原文提醒，除条款允许的情况外，Places 内容不能预取、存储或缓存。 这里有个常见误解：Google Cloud 的预算提醒不会帮你停服务。[预算文档](https://cloud.google.com/billing/docs/how-to/budgets)原文写的是，只发提醒的预算不会自动限制 Google Cloud 或 Google Maps Platform 的用量和花费，只是通知你；真正能卡住用量的是每个 API 的配额，Google 在[限制 API 用量](https://cloud.google.com/apis/docs/capping-api-usage)一页里教你按每天、每分钟设上限。Places API (New) 的配额按「每个 API 方法、每个项目」分开算，所以 Text Search、Place Details 要分别设。 我们是预付余额，按次扣钱，余额不够时接口返回 402 `quota_exhausted`，不会产生欠费，最坏情况就是把充进去的钱用完。这一点适合不想盯账单的小团队，但也意味着你要自己留够余额，否则定时任务会在半夜停下。两种做法各有代价，选哪一种取决于你更怕账单超支，还是更怕任务中断。 ## 代码怎么改：一个 Python 函数的前后对照 下面是一个典型的 Places API (New) 调用：用 Text Search 搜一个品类，字段遮罩带上评分、电话、网站和评论。这段是照 Google 文档写的配置示例，我们没有用 Google 的 Key 运行。 ```text # 改之前：Google Places API (New) Text Search（配置示例，未运行） import os, requests def google_places(query: str, page_token: str | None = None): body = {"textQuery": query, "pageSize": 20} if page_token: body["pageToken"] = page_token r = requests.post( "https://places.googleapis.com/v1/places:searchText", json=body, headers={ "X-Goog-Api-Key": os.environ["GOOGLE_MAPS_API_KEY"], # 带上 places.reviews，整次请求按 Text Search Enterprise + Atmosphere 计费 "X-Goog-FieldMask": "places.id,places.displayName,places.formattedAddress," "places.rating,places.userRatingCount,places.nationalPhoneNumber," "places.websiteUri,places.reviews,nextPageToken", }, timeout=30, ) r.raise_for_status() return r.json() ``` 换成我们的接口后，搜索和评论分成两个能力：搜索一次拿 50 家基本信息，评论按需对感兴趣的店再调。字段名按上一节的对照表改。下面这段我们在写稿时真跑过，参数和返回与本文实测一致。 ```text # 改之后：EveryInfra import os, requests API = "https://api.everyinfra.com/api/v1/social" HEAD = {"Authorization": f"Bearer {os.environ['EVERYINFRA_API_KEY']}"} def call(action: str, params: dict) -> dict: r = requests.post(API, headers=HEAD, timeout=120, json={"platform": "google_maps_reviews", "action": action, "params": params}) r.raise_for_status() # 401/422 不扣钱，直接抛出 return r.json() def places(keyword: str, city: str, country: str, limit: int = 50) -> list[dict]: return call("search", {"keyword": keyword, "location": city, "country": country, "limit": limit})["results"] def reviews(place_url: str, since: str | None = None, pages: int = 1) -> list[dict]: out, token = [], None for _ in range(pages): # 同步最多两页（200 条） p = {"url": place_url, "sort": "newest", "limit": 100} if since: p["since"] = since if token: p["page_token"] = token j = call("reviews", p) out += j["results"] token = j.get("next_page_token") if not token: break return sorted(out, key=lambda x: x.get("posted_at") or "", reverse=True) ``` 改的时候有三处要留意。第一，评论接口要的是地点的地图链接，不是裸的 place ID；搜索结果里的 `url` 已经带了 `query_place_id`，直接传进去最稳。第二，`sort` 只认 `newest` 和 `relevance`，照搬旧版 Places API 的 `most_relevant` 会得到 422。第三，返回里的 `billing.charged_usd` 每次都有，建议记进日志，月底对账时和[失败退款对账那篇实战指南](/build/failure-refund-reconciliation)的做法一样，按 `id` 汇总。 ## 接进 AI agent：Google 的 MCP 和我们的 MCP Google 现在也有自己的 MCP 服务。[Maps Experience agent tools](https://developers.google.com/maps/ai/maps-experience-agent-tools)（以前叫 Maps Grounding Lite）是一个支持 Model Context Protocol 的远程服务，工具包括搜地点、查天气、算路线，以及把地名和地图链接解析成 place ID。它分 Essentials 和 Pro 两个 SKU：Essentials 每次搜索最多回 5 个地点，不带评论里的信息；Pro 能回最多 10 个地点、带「评论里的要点」，但只对白名单客户开放，要联系销售。价格表里 Maps Grounding Essentials 每月免费 1 万次，之后每 1,000 次 $7.00。另一条路是 Gemini API 里的 [Grounding with Google Maps](https://ai.google.dev/gemini-api/docs/maps-grounding)，Gemini 3 及以后的模型每月共享 5,000 次免费，之后每 1,000 次 $14。 | | Google Maps Experience agent tools（Essentials） | Grounding with Google Maps | EveryInfra MCP | | --- | --- | --- | --- | | 地址 | Google 的 MCP 服务 | 只在 Gemini 模型里 | `https://api.everyinfra.com/mcp` | | 每次搜索几个地点 | 最多 5 个 | 由模型决定 | 最多 50 个 | | 评论原文 | 不给 | 不给原文，给带引用的回答 | 每次最多 100 条 | | 每月免费 | 1 万次 | 5,000 次（Gemini 3 起） | 无，$1 一次性试用 | | 之后每 1,000 次 | $7.00 | $14.00 | 每次 $0.001389，合每 1,000 次 $1.389 | | 能不能换模型 | 任何支持 MCP 的客户端 | 只能是 Gemini | 任何支持 MCP 的客户端 | 我们的 MCP 地址是 `https://api.everyinfra.com/mcp`。2026 年 11 月 9 日 00:23（新加坡时间）不带 Key 调 `tools/list`，返回 12 个工具，取地图评论用的是 `everyinfra_call_api`，参数就是 REST 请求体里的 `platform`、`action`、`params`。Claude Code 这类支持远程 MCP 的客户端，配置写成这样： ```text { "mcpServers": { "everyinfra": { "type": "http", "url": "https://api.everyinfra.com/mcp", "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" } } } } ``` 00:30:30（新加坡时间），我们通过 MCP 调了一次 `everyinfra_call_api`，参数是马德里那家药店的最新 5 条西语评论（`limit=5`）。5.36 秒后返回 5 行，扣费 $0.001389，和 REST 接口同价。这里要提醒一点：我们按调用次数收费，取 5 条和取 100 条价格一样，所以让 agent 取评论时，`limit` 直接写 100 更划算。两边的 MCP 定位其实不同：Google 的工具是给模型「回答问题」用的，返回摘要和地点 ID，方便你再在 Google 地图上显示；我们的工具是给模型「拿原始数据」用的，返回整页评论，方便模型自己统计和归类。[我们的 MCP 页面](/mcp-server)列了各客户端的配置写法，协议本身见 [MCP 规范](https://modelcontextprotocol.io/specification/2025-11-25)。 ## 什么时候官方 Places API 更合适 前面的价格和实测都偏向「批量拿数据」的场景。换个角度，下面这些情况我们建议继续用 Google 的 Places API，或者至少不要整个换掉。 免费额度内的小用量，前面「免费额度」一节已经算出交叉点；除此之外还有四种情况。 第一，你要在 App 或网站里给用户实时显示地点信息。我们一次 5–14 秒（Google 的耗时我们没测）；Google 还有 [Places UI Kit](https://developers.google.com/maps/documentation/javascript/places-ui-kit/overview) 这类现成组件，2026 年 10 月 27 日的[官方博客](https://mapsplatform.google.com/resources/blog/drive-confident-place-decisions-with-immersive-maps-live-crowd-signals-and-responsive-map-styling/)刚宣布 iOS 版 Places UI Kit 能显示热门时段和实时拥挤度。实时显示、在地图上点选地点这类场景，Google 是专门为它设计的。 第二，你需要我们没有的功能。[Autocomplete (New)](https://developers.google.com/maps/documentation/places/web-service/place-autocomplete)（输入框联想地点）、地址校验、按坐标查附近（Nearby Search 的圆形范围）、设施字段筛选、地点照片的高清版本、AI 生成的评论摘要，我们都没有。搜「google places autocomplete api alternative」的人，本文帮不上忙。 第三，你需要和其他 Google 服务配合。Places API 返回的 place ID 可以直接用在路线、地理编码、地图标记上；我们的结果里 `place_id` 是同一个 Google 地点 ID，可以拿去和 Google 的接口对齐，但路线、地图这些能力要回到 Google。 第四，你更看重授权清楚。用 Google 的接口，你和 Google 之间有[服务条款](https://cloud.google.com/maps-platform/terms)约定你能怎么用；用我们拿到的公开数据，使用是否合规要你自己按所在地区的法律和平台条款判断，站内评论长文的合规一节列了几条要注意的地方。我们不提供法律意见。 ## Google 的条款：能存什么、怎么展示 很多人换掉 Places API 的真实原因不是价格，而是条款不允许他们做想做的事。Google 的 [Places API 政策页](https://developers.google.com/maps/documentation/places/web-service/policies)（2026 年 11 月 6 日更新）在「缓存和抓取限制」一条里写得很明确，我们截下了原文： ![网页截图：Google for Developers 的 Places API 政策页，青绿色框标出「Caching and scraping restrictions」一条原文：只能按服务专属条款明确允许的方式缓存或存储 Google 地图内容；不得为在服务之外使用而导出、提取或抓取 Google 地图内容，例如不得在服务之外预取、索引、存储或再分发，不得批量下载地图瓦片、街景图像、地理编码、路线、地点信息等，也不得复制和保存商家名称、地址或用户评论。](https://everyinfra.com/articles/google-places-api-alternative/img-shot-policy.webp) Google 原文：不得复制和保存商家名称、地址或用户评论。2026-11-09 截图。 [Google for Developers 截图](https://developers.google.com/maps/documentation/places/web-service/policies) 条款允许保存的只有两样。place ID 不受缓存限制，可以无限期保存，[Place ID 文档](https://developers.google.com/maps/documentation/places/web-service/place-id)建议超过 12 个月的 ID 免费刷新一次；经纬度可以临时缓存最多连续 30 天，之后必须删除，这一条写在 2026 年 10 月 28 日修订的[服务专属条款](https://cloud.google.com/maps-platform/terms/maps-service-terms)第 14.3 条。同一份条款第 14.2 条还规定，Places API 的内容不能和非 Google 的地图一起使用。展示时还要按政策页的要求标注 Google 地图的署名，评论要带作者信息和链接。 所以如果你的需求是「把一批诊所和它们的评论存进数据库，每周跑一次分析」，Places API 的条款本身就不支持这种用法，跟价格无关。反过来，如果你只是在自己的 App 里、在 Google 地图旁边显示一家店的评分和 5 条评论，Places API 是完全合规、也最省事的选择。 欧洲用户还要多看一份条款。Google 的 [EEA 常见问题](https://developers.google.com/maps/comms/eea/faq)写明，2025 年 7 月 8 日起，计费地址在欧洲经济区的项目适用单独的 EEA 服务条款：新项目里，Places API (New) 和旧版的内容不能再和任何地图（包括 Google 地图）一起显示，要在地图上显示地点内容，得改用 Places UI Kit；同时去掉了「不得和非 Google 地图一起使用」等三条限制。西班牙、法国、德国的开发者在选型时要按这一版条款看。 ## 迁移检查单：六步做完 如果算完账决定换，下面是我们建议的顺序。动画里青绿框依次走过六步，第 5 步拿同一批 place ID 双跑一周是最关键的一步。 ![流程动画，六个方框分两行排列，青绿色高亮框依次移动：01 盘点账单，按 SKU 列出每月请求数；02 对字段，把 fieldMask 换成我们的字段名；03 换地点搜索，每次 50 家，深翻页走异步；04 换评论，每次 100 条，用 sort 和 since；05 双跑一周，同一批 place_id 对账；06 留下 Google 的部分，地图展示仍按其条款。](https://everyinfra.com/articles/google-places-api-alternative/fig-02-migration-flow.zh.light.svg) 第一步，在 Google Cloud 控制台的 [Maps 用量报表](https://developers.google.com/maps/billing-and-pricing/reporting-and-monitoring)里按 SKU 列出过去三个月每月的请求数，重点看 Enterprise + Atmosphere 两档，它们通常是账单里最大的一块。第二步，按上面的字段对照表，把代码里的字段遮罩换成我们的字段名，没有对应的字段先列出来，决定是放弃还是继续从 Google 取。第三步，把批量搜索换成 `google_maps_reviews/search`，每次 50 家；要覆盖一个城市，用多个品类词和街区组合去查，按 `place_id` 去重。第四步，把评论换成 `google_maps_reviews/reviews`，日常监控用 `since` 只取新评论，没有新评论时不扣钱。 第五步最关键：拿同一批 place ID，两边同时跑一周，逐个对评分、评论数、营业状态，差异大的地点人工看一眼。第六步，凡是要在地图上给用户看的部分，继续留在 Google，按它的条款展示。这一步的意思是，多数团队最后是两边并用，而不是全换：用户界面用 Google，后台分析用我们。 ## 最近的变化（2026 年 10 月到 11 月） 2026 年 11 月 4 日，[Places (New) SKU 说明页](https://developers.google.com/maps/billing-and-pricing/sku-details/places)更新，页面里已经列出 Maps Experience agent tools 的计费事件，Resolution API 的请求按 Text Search IDs Only SKU 计（免费）。对读者的意思是：用 Google 的 MCP 把地名解析成 place ID 不花钱，取地点信息才花钱。 2026 年 10 月 28 日，[Google Maps Platform 服务专属条款](https://cloud.google.com/maps-platform/terms/maps-service-terms)修订。Places API 一节的缓存规则（place ID 可长期存、经纬度最多 30 天）没有放宽。对读者的意思是：想长期存地点和评论做分析，仍然不在条款允许范围内。 2026 年 10 月 27 日，Google 在[官方博客](https://mapsplatform.google.com/resources/blog/drive-confident-place-decisions-with-immersive-maps-live-crowd-signals-and-responsive-map-styling/)宣布 iOS 版 Places UI Kit Pro 正式可用，地点详情可以显示热门时段和实时拥挤度。对读者的意思是：在 App 里给用户看地点，Google 的现成组件越来越全，这一类需求更没有理由换。 2026 年 10 月 22 日，[Maps Demo Key 文档](https://developers.google.com/maps/demo-key)更新：不用绑卡就能拿一个演示用的 Key，每个 API 有每日上限，用完当天暂停、不会扣钱；但文档注明，用户生成的内容（照片和评论）不能通过演示 Key 获取。对读者的意思是：想先免费试评论接口，演示 Key 试不了，必须开计费账户。 ## 上手：三步把地点和评论换过来 第一步，在[快速上手](/docs#quickstart)注册拿到 API Key；新账户给 everyinfra/everyinfra-agent-plugins 和 everyinfra/seo-skills 两个 GitHub 仓库点星后，可以在控制台领 $1 试用额度，24 小时内有效。这 $1 能调多少次，按[价格页](/pricing)上各项能力当时的单价折算。第二步，用本文的 curl 先搜一次你最常用的品类和城市，看返回的 `results` 和 `billing.charged_usd`。第三步，把代码换成上面的 Python 函数，或者在 agent 里加 MCP 配置。Google 地图评论的能力总览在 [Google 地图评论接口页](/google-maps-reviews-api)，三项能力各有说明页：[地点搜索 `google_maps_reviews/search`](/google-maps-reviews-api/search)、[地点详情 `google_maps_reviews/profile`](/google-maps-reviews-api/profile)、[评论 `google_maps_reviews/reviews`](/google-maps-reviews-api/reviews)；按品类和城市查商家库的 [`google_maps_reviews/business_listings`](/google-maps-reviews-api/business_listings) 每次 20 家、$0.015361，适合要「评论最多的前 20 家」的场景。 同一批地点想对照别家点评站，可以看 [Yelp 接口](/yelp-api)；所有能力都可以在[基础设施市场](/market)在线试。 ## 常见问题 **Google Places API 免费吗？** 部分免费。2025 年 3 月 1 日起，每个核心 SKU 每月有固定免费额度：Essentials 档 1 万次、Pro 档 5,000 次、Enterprise 和 Enterprise + Atmosphere 档 1,000 次，超过后按价格表收费；只取 ID 的 Text Search 和 Place Details 不限次数免费。另外有不用绑卡的演示 Key，但拿不到评论。 **Google Places API 怎样拿到 5 条以上的评论？** 拿不到。Places API (New) 的 `reviews` 字段原文写明最多 5 条、按相关度排序，没有翻页参数；旧版接口的 `reviews_sort=newest` 只能改排序，上限还是 5 条。要更多评论只能换别的数据来源，比如本文的 `google_maps_reviews/reviews`，每次 100 条、翻页最多 400 条。 **Google Places API 的评论能按时间排序吗？** 新版不能，只有相关度一种排序；旧版 Place Details 有 `reviews_sort=newest`，但旧版已是 Legacy 状态。我们的评论接口 `sort` 支持 `newest` 和 `relevance`，另有 `since` 只取某天以后的评论。 **Google Places 评论接口多少钱？** 带 `reviews` 字段时，Place Details 按 Enterprise + Atmosphere 档每 1,000 次 $25，Text Search 按同档每 1,000 次 $40（每次最多 20 个地点），每月前 1,000 次免费；印度计费账户分别是 $7.50 和 $12.00，每月前 7,000 次免费。按每 1,000 条评论算，Place Details 路线 $5.00，Text Search 路线 $0.40。 **有没有免费的 Google Places API 替代？** 完全免费、又能稳定批量拿 Google 地图评论的，我们没有找到。小用量时 Google 自己的免费额度就是最好的免费方案；开放的地点数据集可以免费下载地点和坐标，但没有 Google 地图的评分和评论。我们只有一次性 $1 试用，之后按次付费。 **为什么我的 Places API 账单突然很高？** 最常见的原因是字段遮罩里带了高档字段（比如 `reviews`），整次请求按最贵的档位计费；其次是前端没有防抖，Autocomplete 或 Place Details 被反复触发。Reddit 上那篇 $6k 账单的求助帖，回帖建议先在用量指标里查是哪个接口暴涨、再设每日配额。Google 的预算提醒不会自动停服务，配额才会。 ## 方法和边界 本文 Google 一侧的数字全部来自 2026 年 11 月 9 日读取的官方页面，没有调用 Google 的接口，所以「Text Search 带评论每页 20 个地点各 5 条」是按文档推算的最好情况，实际每家返回几条评论、空结果怎么计费，以你的账单为准。月账计算假设免费额度全部用在这一个 SKU 上，没有算 Google 给大客户的协议价和订阅套餐。我们一侧是同一天 21 次请求、三个城市、各一个品类的样本，评论构成只代表这三家店，不代表品类整体；耗时是从新加坡发出、单次测得，不同地区和时段会不同。 本文也有没测到的部分。Google 的 Nearby Search（按坐标和半径查附近）、地点照片、Autocomplete 我们都没有对应能力，所以没有比；我们的 `google_maps_reviews/business_listings` 按品类和城市取评论最多的前 20 家，本文只引用了目录价，没有真调。三个城市的样本都是医疗相关品类，换成餐厅、酒店这类评论更多、照片更多的品类，5 条上限能看到的比例会更低，单家调一次 100 条能覆盖的比例也会下降，建议用你自己最常查的品类先跑一小批再下结论。 ## 参考资料 1. [Google Maps Platform core services pricing list（Places API (New) 各 SKU 价格、免费额度、阶梯价）](https://developers.google.com/maps/billing-and-pricing/pricing)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Places (New) SKU details（字段遮罩按最高 SKU 计费、各档触发字段）](https://developers.google.com/maps/billing-and-pricing/sku-details/places)，Google for Developers，2026-11-04 更新，2026-11-09 读取。 1. [Place Details (New)（rating 触发 Enterprise、reviews 触发 Enterprise + Atmosphere、最多 5 条）](https://developers.google.com/maps/documentation/places/web-service/place-details)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [REST Resource: places（reviews 按相关度排序、最多 5 条；Review 对象字段）](https://developers.google.com/maps/documentation/places/web-service/reference/rest/v1/places)，Google for Developers，2026-10-27 更新，2026-11-09 读取。 1. [Text Search (New)（pageSize 最多 20、一个查询最多 60 条）](https://developers.google.com/maps/documentation/places/web-service/text-search)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Nearby Search (New)（maxResultCount 1–20、EEA 条款提示）](https://developers.google.com/maps/documentation/places/web-service/nearby-search)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Place Data Fields (New)](https://developers.google.com/maps/documentation/places/web-service/data-fields)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Places API usage and billing（字段遮罩省钱、配额按 API 方法分开）](https://developers.google.com/maps/documentation/places/web-service/usage-and-billing)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Policies and attributions for Places API（缓存和抓取限制、署名要求）](https://developers.google.com/maps/documentation/places/web-service/policies)，Google for Developers，2026-11-06 更新，2026-11-09 读取。 1. [Place IDs（可长期保存、超过 12 个月建议刷新、NOT_FOUND）](https://developers.google.com/maps/documentation/places/web-service/place-id)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Google Maps Platform Service Specific Terms（第 14 节 Places API：不得与非 Google 地图一起使用、经纬度最多缓存 30 天）](https://cloud.google.com/maps-platform/terms/maps-service-terms)，Google，2026-10-28 修订，2026-11-09 读取。 1. [Google Maps Platform Terms of Service](https://cloud.google.com/maps-platform/terms)，Google，2026-08-26 修订，2026-11-09 读取。 1. [Google Maps Platform March 2025 changes（$200 赠送额度改为每个 SKU 的免费额度）](https://developers.google.com/maps/billing-and-pricing/march-2025)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Billing and pricing FAQ](https://developers.google.com/maps/billing-and-pricing/faq)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Billing and pricing overview](https://developers.google.com/maps/billing-and-pricing/overview)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Pricing categories（Essentials、Pro、Enterprise）](https://developers.google.com/maps/billing-and-pricing/pricing-categories)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Pay-as-you-go pricing](https://developers.google.com/maps/billing-and-pricing/pay-as-you-go)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Google Maps Platform core services pricing list - India（Enterprise + Atmosphere 每月免费 7,000 次）](https://developers.google.com/maps/billing-and-pricing/pricing-india)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Place Details (Legacy)（reviews_sort=newest、最多 5 条）](https://developers.google.com/maps/documentation/places/web-service/legacy/details)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Migrate to Places API (New)](https://developers.google.com/maps/documentation/places/web-service/legacy/migrate-overview)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Places API (New) release notes（2026-08-06 entrances、2026-05-20 transitStation 等）](https://developers.google.com/maps/documentation/places/web-service/release-notes)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Choose fields to return（字段遮罩写法）](https://developers.google.com/maps/documentation/places/web-service/choose-fields)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Place Photos (New)](https://developers.google.com/maps/documentation/places/web-service/place-photos)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Autocomplete (New)](https://developers.google.com/maps/documentation/places/web-service/place-autocomplete)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Places UI Kit overview](https://developers.google.com/maps/documentation/javascript/places-ui-kit/overview)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Places Aggregate API overview](https://developers.google.com/maps/documentation/places-aggregate/overview)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Place Types (New)](https://developers.google.com/maps/documentation/places/web-service/place-types)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Places API (New) overview](https://developers.google.com/maps/documentation/places/web-service/op-overview)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Maps Experience agent tools（原 Maps Grounding Lite，MCP 服务，Essentials 每次最多 5 个地点）](https://developers.google.com/maps/ai/maps-experience-agent-tools)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Resolution API（名称和地图链接解析成 place ID）](https://developers.google.com/maps/ai/grounding-lite/resolution-api)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Google Maps Platform Code Assist toolkit（MCP）](https://developers.google.com/maps/ai/mcp)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Grounding with Google Maps（Gemini API，每月 5,000 次免费后每 1,000 次 $14）](https://ai.google.dev/gemini-api/docs/maps-grounding)，Google AI for Developers，2026-11-09 读取。 1. [Gemini Developer API pricing](https://ai.google.dev/gemini-api/docs/pricing)，Google AI for Developers，2026-11-09 读取。 1. [Maps Demo Key（不用绑卡、每日上限、评论和照片不可用）](https://developers.google.com/maps/demo-key)，Google for Developers，2026-10-22 更新，2026-11-09 读取。 1. [Get a Maps Demo Key with no credit card](https://mapsplatform.google.com/maps-demo-key/)，Google Maps Platform，2026-11-09 读取。 1. [Important changes for EEA customers: FAQ（2025-07-08 起 EEA 条款）](https://developers.google.com/maps/comms/eea/faq)，Google for Developers，2026-11-03 更新，2026-11-09 读取。 1. [Create, edit, or delete budgets and budget alerts（只发提醒的预算不会自动限制用量）](https://cloud.google.com/billing/docs/how-to/budgets)，Google Cloud，2026-11-04 更新，2026-11-09 读取。 1. [Capping API usage（按每天、每分钟设配额）](https://cloud.google.com/apis/docs/capping-api-usage)，Google Cloud，2026-10-26 更新，2026-11-09 读取。 1. [Reporting and monitoring（Maps 用量报表）](https://developers.google.com/maps/billing-and-pricing/reporting-and-monitoring)，Google for Developers，2026-10-27 更新，2026-11-09 读取。 1. [Drive confident place decisions with immersive maps, live crowd signals, and responsive map styling](https://mapsplatform.google.com/resources/blog/drive-confident-place-decisions-with-immersive-maps-live-crowd-signals-and-responsive-map-styling/)，Google Maps Platform 博客，2026-10-27，2026-11-09 读取。 1. [Moving from the Google Earth desktop app to the web](https://mapsplatform.google.com/resources/blog/moving-from-the-google-earth-desktop-app-to-the-web-whats-happening-and-when/)，Google Maps Platform 博客，2026-10-29，2026-11-09 读取。 1. [Neurun makes sure no fan gets lost in the crowd using Google Maps Platform](https://mapsplatform.google.com/resources/blog/neurun-makes-sure-no-fan-gets-lost-in-the-crowd-using-google-maps-platform/)，Google Maps Platform 博客，2026-10-20，2026-11-09 读取。 1. [Powering the next era of agentic experiences: announcing new grounding capabilities](https://mapsplatform.google.com/resources/blog/powering-the-next-era-of-agentic-experiences-announcing-new-grounding-capabilities/)，Google Maps Platform 博客，2026-04-22，2026-11-09 读取。 1. [Model Context Protocol specification 2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25)，Model Context Protocol，2026-11-09 读取。 1. [PLEASE HELP!!!! I got a bill of $6k using Google Places API](https://www.reddit.com/r/webdevelopment/comments/1obolm0/please_help_i_got_a_bill_of_6k_using_google/)，Reddit r/webdevelopment，2026-11-09 读取。 1. [New to Google Maps Places New API: Is 10k Requests per month really free?](https://www.reddit.com/r/googlecloud/comments/1kzpdvo/new_to_google_maps_places_new_api_is_10k_requests/)，Reddit r/googlecloud，2026-11-09 读取。 1. [Google Maps & Places API pricing. Not to beat a dead horse](https://www.reddit.com/r/webdev/comments/1gxqw6a/google_maps_places_api_pricing_not_to_beat_a_dead/)，Reddit r/webdev，2026-11-09 读取。 1. [Google Maps API Pricing Change After March 1, 2025](https://www.reddit.com/r/googlecloud/comments/1i3cgq0/google_maps_api_pricing_change_after_march_1_2025/)，Reddit r/googlecloud，2026-11-09 读取。 1. [Open Source Google Maps API Alternative（视频，开放地点数据集自建地图）](https://www.youtube.com/watch?v=EdIkmp5Yj7I)，YouTube，2024-06-26，2026-11-09 读取字幕。 1. [Google Maps API Is INSANE: Build Real-World Apps with Places API（视频，开通计费和字段遮罩演示）](https://www.youtube.com/watch?v=3MkOJzxptfU)，YouTube，2026-09-15，2026-11-09 读取字幕。 1. [EveryInfra 数据目录（google_maps_reviews 各能力 price_usd、参数、字段）](https://api.everyinfra.com/api/v1/social/catalog)，EveryInfra，2026-11-09 00:14 读取。