Google Places API alternative：千家地点实测比价

同样拿 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、或者正在搜「google places api alternative」的开发者。站内已经有一篇讲三条路怎么批量抓 Google 地图评论的长文，和一篇给牙科诊所做 Google 点评竞品周报的实战；本篇不重复那两篇，只讲一件事：从 Google 官方的 Places API (New) 换过来，钱怎么算、字段怎么对、哪些情况不该换。Google 一侧我们只读公开文档、价格表和条款，2026 年 11 月 9 日 00:14–00:18（新加坡时间）逐页打开存档，没有用 Google 的 Key 调用；我们这一侧全部是同一天 00:19–00:30 的真调，文中每个数字都能回到原始返回。

先看结论：google places api alternative 按用量怎么选

先把结论放前面。用 Places API 的人大致分三种：在自己的 App 里给用户显示地点信息的、批量拿地点和评论做分析的、给 AI agent 当地点工具的。三种人该选的不一样，下面这张表按「每月多少个地点、要不要评论」给出更便宜的一边，价格是 2026 年 11 月 9 日读到的 Google 公开价和我们的目录价，Google 一侧已经扣掉每月免费额度，并假设这是计费账户里唯一的用量。

这张表的意思是：Google 的免费额度很实在，小用量和「显示给用户看」这两种场景，没有理由换。换过来真正省钱的是两种情况：一是你要的不是评论、只是一大批地点的评分和联系方式，这时我们每次 50 家、每 1,000 家 $0.0278，比 Google 便宜两个数量级；二是你要的评论不止 5 条，或者要按时间看最新的评论，这件事 Google 的接口按设计就做不到，不是多花钱能解决的。后面每一节都会把这张表里的数拆开算一遍。

Google Places API (New) 怎么计费：字段遮罩决定 SKU

Places API (New) 的计费单位不是「一个地点」，而是「一次请求」，价格看你在 X-Goog-FieldMask 里要了哪些字段。Google 的 SKU 说明页写得很直接：字段遮罩里的字段如果来自几个 SKU，整次请求按其中最贵的那个 SKU 计费。比如你只想要店名和地址，但顺手加了一个 rating，这次请求就从 Pro 档跳到 Enterprise 档；再加一个 reviews，就跳到最贵的 Enterprise + Atmosphere 档。下面是我们 2026 年 11 月 9 日截下的原文，页面底部写着最后更新于 2026 年 11 月 4 日。

把这条规则和价格表放在一起看，就知道评论为什么贵。Place Details (New) 文档专门有一段讲评分和评论：rating 和 userRatingCount 触发 Place Details Enterprise SKU；reviews 和 reviewSummary 触发 Place Details Enterprise + Atmosphere SKU，返回最多五条用户评论。Google 自己在那一段给的省钱建议是：如果你只需要星级和评论数，就别要 reviews，让请求停在 Enterprise 档。下表是本文要用到的几个 SKU，单位是每 1,000 次请求，取自价格表第一个用量档（免费额度之后到每月 10 万次）。

表里最后一列是本文后面所有计算的关键。Text Search (New) 一页最多 20 个地点：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 的三月变更说明写的是：原来每月 $200 的赠送额度取消，改为每个核心 SKU 每月固定一段免费用量，Essentials 档 1 万次、Pro 档 5,000 次、Enterprise 档 1,000 次。这段免费额度是按 SKU 算的，不是按项目算：同一个计费账户下所有项目加在一起，每个 SKU 每月共享这一段。Reddit 的 r/googlecloud 上有人问「每月 1 万次免费是真的吗」，回帖的人也提醒，账单报表比用量面板晚几个小时，测试时最好先设硬上限。

同样 1,000 个地点：Google 四种取法和我们的标价

把上一节的价格套到「1,000 个地点」上。Google 一侧有四种常见取法，我们一侧有三种组合，下表都按标价算、先不扣免费额度，这样才能看出用量大时的单价差。Google 的请求数按每页 20 个地点算；我们的搜索每次最多 50 家（目录 max_limit 是 50），评论每次最多 100 条。

这张图要先看中间那两根柱子。很多人以为 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 路线前 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 价是全球价格表；印度计费账户另有印度价格表，Place Details Enterprise + Atmosphere 每月免费 7,000 次、之后每 1,000 次 $7.50，Text Search Enterprise + Atmosphere 每月免费 7,000 次、之后 $12.00，印度用户的交叉点要按那张表重算。

5 条评论上限：在 150 家医疗点上意味着什么

Google 的 Place 资源说明里，reviews 字段的原文是「关于这个地点的评论列表，按相关度排序，最多返回 5 条」。本篇要回答的是：在真实的一批地点上，5 条到底占全部评论的多少。我们在 2026 年 11 月 9 日 00:19–00:22（新加坡时间）搜了三个城市、三个公共卫生相关的品类，每个城市 50 家，用搜索结果里的 review_count 加总全部评论数，再按「每家最多 5 条」和「每家一次调用最多 100 条」分别算能看到多少。

三个城市里，芝加哥的急诊诊所评论最多，一家中位 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。

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 条、评论正文截短、点评人名字隐去，青绿框标出返回条数和扣费。

{"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 星」这个信号。第一页的排序也不是严格按时间，有几条更早的评论夹在中间，这一点站内那篇评论抓取长文专门测过，处理办法是拿回来以后按 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 个地点的请求算不算成功，原文没有写；而我们的目录和价格页都写明失败或空结果不计费，这次实测也对上了。还有一个坏链接的测试：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%。

这不能证明 Google 的相关度排序会故意挑好评，样本只有三家店，排序规则 Google 也没有公开。能说的是：按相关度排在前面的评论，通常是篇幅长、有人点赞、有商家回复的那些，在这家新加坡诊所上，它们恰好全是 5 星；而「最近有人在抱怨什么」只有按时间看才看得到。Places API (New) 的 reviews 只有相关度一种排序，不能改。旧版 Places API 的 Place Details 有一个 reviews_sort=newest 参数，旧版文档里还在，但上限同样是 5 条，而且旧版已经进入 Legacy 状态，新项目不建议再用。

字段对照：Places API 的字段在我们这边叫什么

迁移最费时间的往往是字段名。下表左边是 Places API (New) 的字段（Text Search 里要加 places. 前缀），中间是它触发的 SKU，右边是我们对应的字段和能力。没有对应的照实写「没有」。

对照下来，我们这边有、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 去重的文章写了怎么做连锁分店和搬迁记录。第二，异步提交那一刻就扣费（$0.001389），任务结果在 GET /api/v1/jobs/{job_id} 里取，查询结果不另外收钱；如果任务最后失败，会按同一笔记录退款。

地点 ID 会变：两边都要定期刷新

迁移时很多人默认 place ID 是永久主键，这一点要先纠正。Google 的 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 去重那篇有完整的判断规则。还要记住一点：搜索结果里偶尔有坐标落在城市中心的行（新加坡那 3 行就是），这种行的 ID 是否更容易变，我们没有验证；建议入库时单独打一个标记，方便以后人工复核。

失败、空结果和报错：哪些情况扣钱

这次 21 次请求里 13 次扣费、8 次 $0：7 次是下表里的报错或空结果，另 1 次是 00:30:23 用 GET /api/v1/jobs/{job_id} 取异步结果，它不算失败，不在表里。表里另加了一行扣了钱的乱码搜索作对照。时间都是 2026 年 11 月 9 日新加坡时间。

乱码那一行值得单独说：我们原本想用它测空结果，结果接口按其中的 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。迁移脚本按这个字段决定要不要重试就行，参数错误不用写退避重试。

耗时也照实说：搜索和详情一次 10–14 秒，评论 5–13 秒，空结果反而最慢（24 秒和 37 秒），因为接口要确认确实没有数据才会退款。Google 一侧的耗时我们没有测（本文没有用 Google 的 Key 调用），所以这里不做两边对比。只看我们自己的数：一次 5–14 秒，空结果 24–37 秒，适合后台批量任务，不适合放在用户点一下就要出结果的地方。

防账单失控：预算提醒不会自动停

Places API 被抱怨最多的不是单价，而是账单失控。Reddit 的 r/webdevelopment 上有一篇求助帖，标题写的是用 Places API 收到 $6k 账单，发帖人在回帖里说可能是代码进了死循环。回帖里有人说 Google 一般最多减免 50%；另一位列了四步：开账单工单；在 API 用量指标里找出是哪个接口暴涨，常见的是 Autocomplete 或 Place Details 被反复触发；立刻设每日配额和预算提醒；搜索框和前端加防抖和缓存。另一篇 r/webdev 的帖子在 2025 年 3 月改价前讨论价格贵到做不成产品：发帖人说光开发测试就用掉了当时每月 $200 赠送额度里的 $75；回帖里有人说收到 Google 的改价邮件后，估算的新成本「难以承受」，改用了开放地图数据；也有人贴出条款原文提醒，除条款允许的情况外，Places 内容不能预取、存储或缓存。

这里有个常见误解：Google Cloud 的预算提醒不会帮你停服务。预算文档原文写的是，只发提醒的预算不会自动限制 Google Cloud 或 Google Maps Platform 的用量和花费，只是通知你；真正能卡住用量的是每个 API 的配额，Google 在限制 API 用量一页里教你按每天、每分钟设上限。Places API (New) 的配额按「每个 API 方法、每个项目」分开算，所以 Text Search、Place Details 要分别设。

我们是预付余额，按次扣钱，余额不够时接口返回 402 quota_exhausted，不会产生欠费，最坏情况就是把充进去的钱用完。这一点适合不想盯账单的小团队，但也意味着你要自己留够余额，否则定时任务会在半夜停下。两种做法各有代价，选哪一种取决于你更怕账单超支，还是更怕任务中断。

代码怎么改：一个 Python 函数的前后对照

下面是一个典型的 Places API (New) 调用：用 Text Search 搜一个品类，字段遮罩带上评分、电话、网站和评论。这段是照 Google 文档写的配置示例，我们没有用 Google 的 Key 运行。

# 改之前：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 家基本信息，评论按需对感兴趣的店再调。字段名按上一节的对照表改。下面这段我们在写稿时真跑过，参数和返回与本文实测一致。

# 改之后：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 每次都有，建议记进日志，月底对账时和失败退款对账那篇实战指南的做法一样，按 id 汇总。

接进 AI agent：Google 的 MCP 和我们的 MCP

Google 现在也有自己的 MCP 服务。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，Gemini 3 及以后的模型每月共享 5,000 次免费，之后每 1,000 次 $14。

我们的 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 的客户端，配置写成这样：

{
  "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 规范。

什么时候官方 Places API 更合适

前面的价格和实测都偏向「批量拿数据」的场景。换个角度，下面这些情况我们建议继续用 Google 的 Places API，或者至少不要整个换掉。

免费额度内的小用量，前面「免费额度」一节已经算出交叉点；除此之外还有四种情况。

第一，你要在 App 或网站里给用户实时显示地点信息。我们一次 5–14 秒（Google 的耗时我们没测）；Google 还有 Places UI Kit 这类现成组件，2026 年 10 月 27 日的官方博客刚宣布 iOS 版 Places UI Kit 能显示热门时段和实时拥挤度。实时显示、在地图上点选地点这类场景，Google 是专门为它设计的。

第二，你需要我们没有的功能。Autocomplete (New)（输入框联想地点）、地址校验、按坐标查附近（Nearby Search 的圆形范围）、设施字段筛选、地点照片的高清版本、AI 生成的评论摘要，我们都没有。搜「google places autocomplete api alternative」的人，本文帮不上忙。

第三，你需要和其他 Google 服务配合。Places API 返回的 place ID 可以直接用在路线、地理编码、地图标记上；我们的结果里 place_id 是同一个 Google 地点 ID，可以拿去和 Google 的接口对齐，但路线、地图这些能力要回到 Google。

第四，你更看重授权清楚。用 Google 的接口，你和 Google 之间有服务条款约定你能怎么用；用我们拿到的公开数据，使用是否合规要你自己按所在地区的法律和平台条款判断，站内评论长文的合规一节列了几条要注意的地方。我们不提供法律意见。

Google 的条款：能存什么、怎么展示

很多人换掉 Places API 的真实原因不是价格，而是条款不允许他们做想做的事。Google 的 Places API 政策页（2026 年 11 月 6 日更新）在「缓存和抓取限制」一条里写得很明确，我们截下了原文：

条款允许保存的只有两样。place ID 不受缓存限制，可以无限期保存，Place ID 文档建议超过 12 个月的 ID 免费刷新一次；经纬度可以临时缓存最多连续 30 天，之后必须删除，这一条写在 2026 年 10 月 28 日修订的服务专属条款第 14.3 条。同一份条款第 14.2 条还规定，Places API 的内容不能和非 Google 的地图一起使用。展示时还要按政策页的要求标注 Google 地图的署名，评论要带作者信息和链接。

所以如果你的需求是「把一批诊所和它们的评论存进数据库，每周跑一次分析」，Places API 的条款本身就不支持这种用法，跟价格无关。反过来，如果你只是在自己的 App 里、在 Google 地图旁边显示一家店的评分和 5 条评论，Places API 是完全合规、也最省事的选择。

欧洲用户还要多看一份条款。Google 的 EEA 常见问题写明，2025 年 7 月 8 日起，计费地址在欧洲经济区的项目适用单独的 EEA 服务条款：新项目里，Places API (New) 和旧版的内容不能再和任何地图（包括 Google 地图）一起显示，要在地图上显示地点内容，得改用 Places UI Kit；同时去掉了「不得和非 Google 地图一起使用」等三条限制。西班牙、法国、德国的开发者在选型时要按这一版条款看。

迁移检查单：六步做完

如果算完账决定换，下面是我们建议的顺序。动画里青绿框依次走过六步，第 5 步拿同一批 place ID 双跑一周是最关键的一步。

第一步，在 Google Cloud 控制台的 Maps 用量报表里按 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 说明页更新，页面里已经列出 Maps Experience agent tools 的计费事件，Resolution API 的请求按 Text Search IDs Only SKU 计（免费）。对读者的意思是：用 Google 的 MCP 把地名解析成 place ID 不花钱，取地点信息才花钱。

2026 年 10 月 28 日，Google Maps Platform 服务专属条款修订。Places API 一节的缓存规则（place ID 可长期存、经纬度最多 30 天）没有放宽。对读者的意思是：想长期存地点和评论做分析，仍然不在条款允许范围内。

2026 年 10 月 27 日，Google 在官方博客宣布 iOS 版 Places UI Kit Pro 正式可用，地点详情可以显示热门时段和实时拥挤度。对读者的意思是：在 App 里给用户看地点，Google 的现成组件越来越全，这一类需求更没有理由换。

2026 年 10 月 22 日，Maps Demo Key 文档更新：不用绑卡就能拿一个演示用的 Key，每个 API 有每日上限，用完当天暂停、不会扣钱；但文档注明，用户生成的内容（照片和评论）不能通过演示 Key 获取。对读者的意思是：想先免费试评论接口，演示 Key 试不了，必须开计费账户。

上手：三步把地点和评论换过来

第一步，在快速上手注册拿到 API Key；新账户给 everyinfra/everyinfra-agent-plugins 和 everyinfra/seo-skills 两个 GitHub 仓库点星后，可以在控制台领 $1 试用额度，24 小时内有效。这 $1 能调多少次，按价格页上各项能力当时的单价折算。第二步，用本文的 curl 先搜一次你最常用的品类和城市，看返回的 results 和 billing.charged_usd。第三步，把代码换成上面的 Python 函数，或者在 agent 里加 MCP 配置。Google 地图评论的能力总览在 Google 地图评论接口页，三项能力各有说明页：地点搜索 google_maps_reviews/search、地点详情 google_maps_reviews/profile、评论 google_maps_reviews/reviews；按品类和城市查商家库的 google_maps_reviews/business_listings 每次 20 家、$0.015361，适合要「评论最多的前 20 家」的场景。

同一批地点想对照别家点评站，可以看 Yelp 接口；所有能力都可以在基础设施市场在线试。

常见问题

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 价格、免费额度、阶梯价），Google for Developers，2026-11-03 更新，2026-11-09 读取。
2. Places (New) SKU details（字段遮罩按最高 SKU 计费、各档触发字段），Google for Developers，2026-11-04 更新，2026-11-09 读取。
3. Place Details (New)（rating 触发 Enterprise、reviews 触发 Enterprise + Atmosphere、最多 5 条），Google for Developers，2026-11-03 更新，2026-11-09 读取。
4. REST Resource: places（reviews 按相关度排序、最多 5 条；Review 对象字段），Google for Developers，2026-10-27 更新，2026-11-09 读取。
5. Text Search (New)（pageSize 最多 20、一个查询最多 60 条），Google for Developers，2026-11-03 更新，2026-11-09 读取。
6. Nearby Search (New)（maxResultCount 1–20、EEA 条款提示），Google for Developers，2026-11-03 更新，2026-11-09 读取。
7. Place Data Fields (New)，Google for Developers，2026-11-03 更新，2026-11-09 读取。
8. Places API usage and billing（字段遮罩省钱、配额按 API 方法分开），Google for Developers，2026-11-03 更新，2026-11-09 读取。
9. Policies and attributions for Places API（缓存和抓取限制、署名要求），Google for Developers，2026-11-06 更新，2026-11-09 读取。
10. Place IDs（可长期保存、超过 12 个月建议刷新、NOT_FOUND），Google for Developers，2026-11-03 更新，2026-11-09 读取。
11. Google Maps Platform Service Specific Terms（第 14 节 Places API：不得与非 Google 地图一起使用、经纬度最多缓存 30 天），Google，2026-10-28 修订，2026-11-09 读取。
12. Google Maps Platform Terms of Service，Google，2026-08-26 修订，2026-11-09 读取。
13. Google Maps Platform March 2025 changes（$200 赠送额度改为每个 SKU 的免费额度），Google for Developers，2026-11-03 更新，2026-11-09 读取。
14. Billing and pricing FAQ，Google for Developers，2026-11-03 更新，2026-11-09 读取。
15. Billing and pricing overview，Google for Developers，2026-11-03 更新，2026-11-09 读取。
16. Pricing categories（Essentials、Pro、Enterprise），Google for Developers，2026-11-03 更新，2026-11-09 读取。
17. Pay-as-you-go pricing，Google for Developers，2026-11-03 更新，2026-11-09 读取。
18. Google Maps Platform core services pricing list - India（Enterprise + Atmosphere 每月免费 7,000 次），Google for Developers，2026-11-03 更新，2026-11-09 读取。
19. Place Details (Legacy)（reviews_sort=newest、最多 5 条），Google for Developers，2026-11-03 更新，2026-11-09 读取。
20. Migrate to Places API (New)，Google for Developers，2026-11-03 更新，2026-11-09 读取。
21. Places API (New) release notes（2026-08-06 entrances、2026-05-20 transitStation 等），Google for Developers，2026-11-03 更新，2026-11-09 读取。
22. Choose fields to return（字段遮罩写法），Google for Developers，2026-11-03 更新，2026-11-09 读取。
23. Place Photos (New)，Google for Developers，2026-11-03 更新，2026-11-09 读取。
24. Autocomplete (New)，Google for Developers，2026-11-03 更新，2026-11-09 读取。
25. Places UI Kit overview，Google for Developers，2026-11-03 更新，2026-11-09 读取。
26. Places Aggregate API overview，Google for Developers，2026-11-03 更新，2026-11-09 读取。
27. Place Types (New)，Google for Developers，2026-11-03 更新，2026-11-09 读取。
28. Places API (New) overview，Google for Developers，2026-11-03 更新，2026-11-09 读取。
29. Maps Experience agent tools（原 Maps Grounding Lite，MCP 服务，Essentials 每次最多 5 个地点），Google for Developers，2026-11-03 更新，2026-11-09 读取。
30. Resolution API（名称和地图链接解析成 place ID），Google for Developers，2026-11-03 更新，2026-11-09 读取。
31. Google Maps Platform Code Assist toolkit（MCP），Google for Developers，2026-11-03 更新，2026-11-09 读取。
32. Grounding with Google Maps（Gemini API，每月 5,000 次免费后每 1,000 次 $14），Google AI for Developers，2026-11-09 读取。
33. Gemini Developer API pricing，Google AI for Developers，2026-11-09 读取。
34. Maps Demo Key（不用绑卡、每日上限、评论和照片不可用），Google for Developers，2026-10-22 更新，2026-11-09 读取。
35. Get a Maps Demo Key with no credit card，Google Maps Platform，2026-11-09 读取。
36. Important changes for EEA customers: FAQ（2025-07-08 起 EEA 条款），Google for Developers，2026-11-03 更新，2026-11-09 读取。
37. Create, edit, or delete budgets and budget alerts（只发提醒的预算不会自动限制用量），Google Cloud，2026-11-04 更新，2026-11-09 读取。
38. Capping API usage（按每天、每分钟设配额），Google Cloud，2026-10-26 更新，2026-11-09 读取。
39. Reporting and monitoring（Maps 用量报表），Google for Developers，2026-10-27 更新，2026-11-09 读取。
40. Drive confident place decisions with immersive maps, live crowd signals, and responsive map styling，Google Maps Platform 博客，2026-10-27，2026-11-09 读取。
41. Moving from the Google Earth desktop app to the web，Google Maps Platform 博客，2026-10-29，2026-11-09 读取。
42. Neurun makes sure no fan gets lost in the crowd using Google Maps Platform，Google Maps Platform 博客，2026-10-20，2026-11-09 读取。
43. Powering the next era of agentic experiences: announcing new grounding capabilities，Google Maps Platform 博客，2026-04-22，2026-11-09 读取。
44. Model Context Protocol specification 2025-11-25，Model Context Protocol，2026-11-09 读取。
45. PLEASE HELP!!!! I got a bill of $6k using Google Places API，Reddit r/webdevelopment，2026-11-09 读取。
46. New to Google Maps Places New API: Is 10k Requests per month really free?，Reddit r/googlecloud，2026-11-09 读取。
47. Google Maps & Places API pricing. Not to beat a dead horse，Reddit r/webdev，2026-11-09 读取。
48. Google Maps API Pricing Change After March 1, 2025，Reddit r/googlecloud，2026-11-09 读取。
49. Open Source Google Maps API Alternative（视频，开放地点数据集自建地图），YouTube，2024-06-26，2026-11-09 读取字幕。
50. Google Maps API Is INSANE: Build Real-World Apps with Places API（视频，开通计费和字段遮罩演示），YouTube，2026-09-15，2026-11-09 读取字幕。
51. EveryInfra 数据目录（google_maps_reviews 各能力 price_usd、参数、字段），EveryInfra，2026-11-09 00:14 读取。