google 地图 api 收费

做定位、路线规划或者门店地图的时候，最容易踩的坑是：上线前觉得调用量不大，上线后账单比预估高一截。问题通常不在单价，而在计费维度和你想的不是一回事。这篇把 Google 地图 API 的计费维度拆开，给一套对账和控本的顺序，具体单价和免费额度数字请到站内页面看当期数值。

做定位、路线规划或者门店地图的时候，最容易踩的坑是：上线前觉得调用量不大，上线后账单比预估高一截。问题通常不在单价，而在计费维度和你想的不是一回事。你以为「调了一个接口」，结算系统看到的是三四个不同的计费动作，各自按各自的口径累加。

这篇不背数字，只拆计费维度和控本顺序。具体单价、免费额度这些会变的数值，到站内 /official-api 核对当期数字就行。下面四节分别讲：按什么量收费、哪些用量会叠加、预算怎么设三道闸门、以及什么情况下别急着省钱。

先分清按什么量收费：不是按「接口」而是按「动作」

同一个地图产品下面，动态地图加载、静态图、路线规划、地点检索、地理编码，走的往往是不同的计价条目。你在代码里看到的是一行 SDK 调用，账单里可能是好几行。所以别用「我一天调一万次接口」这种笼统估算，先把动作类型列出来。

唯一不容易错的做法：先把业务动作映射成计费动作，得到「计费动作数」，再去站内 /official-api 把当期单价填进去乘。映射这一层做错了，后面乘法再准也是白算。

• 把每个页面、每个功能用到的地图能力列成清单，标注它属于哪一类计费动作
• 确认该动作是按次、按会话还是按元素计费，口径不同结果差很多
• 用测试环境跑一遍真实用户路径，数出一次典型操作实际产生几笔记费动作
• 把「业务量 → 计费动作数」写成一张换算表，后续所有估算都基于它

别忽略叠加项：一次用户操作可能触发好几笔

用户拖动一次地图、搜索一次地址、点一次路线，在后端可能是地图加载加检索加路径规划三笔账。按接口数估量会系统性低估，按「用户动作链路」估量才接近真实。尤其是移动端，页面切来切去，同一个地图组件被反复重建，账就悄悄上去了。

1. 画出动作链路挑三到五个最典型的用户操作，从前端点击一路跟到后端请求，把每一跳会产生的计费动作记下来，形成链路图。
2. 标出可复用点看链路里哪些结果是可以缓存或复用的，比如同一地址的编码结果、同一区域的静态图，标出来就是省钱位。
3. 给高频入口加约束自动补全、逆地理编码这类高频小请求，统一加防抖和最小触发长度，别让输入框每敲一下就发一次。
4. 验证改完之后用同样的动作链路再跑一遍，对比用量明细里对应接口的调用条数是否下降。

还有一个常被忽略的点：失败重试。如果 SDK 报错后你的代码是无脑重试，一次用户操作可能变成好几笔账，而且是你完全看不到的账。上线前把重试次数和退避策略定死。

预算怎么做：三道闸门管住跑飞

预算不是写一个总数就完了，要能提前拦住跑飞。建议按三道闸门来做，从粗到细，任何一道报警都能让你在账单爆掉之前介入。

三道闸门里，第一道最容易被跳过，因为大家习惯共用云账号。但共用账单意味着你看不出是哪个业务在涨，等发现时往往已经涨了好几周。给地图相关调用单独隔离出项目或标签，是最省事的做法。

• 配额上限设成预期峰值的合理倍数，别设成刚好够用，否则会影响正常突发流量
• 预算告警分两档：一档提醒你去看，一档是真的要动手限流了
• 用量明细按接口名而不是按总量看，总量会掩盖结构性问题
• 把巡检固定成每周一次的动作，别等月底对账才看

什么情况下别急着省钱

省钱套路有适用边界，不是所有场景都该上。下面几种情况下，把功能做对、把稳定性保住，优先级高于压成本。

• 调用量还在免费额度或极低档位内：省下来的量可能还不够你改架构的工时，先把功能跑通再说
• 对时效要求高的场景，比如实时路况、配送调度：靠缓存降本会引入数据偏差，偏差带来的业务损失可能高于省下的调用费
• 有合规或数据来源要求的场景：不要为了便宜换成来源不明的转发渠道，账要算总成本，不只看单价
• 功能还在快速迭代期：这个阶段调用结构每周都在变，过早做精细优化很容易白做

如果你判断下来确实属于「该优化」的那一类，再回到第二、三节的链路图和闸门，按顺序做。反过来，如果你连自己每次用户操作产生几笔记费动作都还说不清，那就先别动优化，先补这个认知。

控本的前提是能算清账，算不清的时候先别省，先去对账。