能否按具体页面统计 Google Maps API 请求？

2026-10-24支付老李

结论

Google Maps Platform 的常规用量和账单报告通常无法按网站的具体页面 URL 路径拆分请求。报告支持项目、API、SKU、凭据（API key）、时间等维度，但浏览器请求携带的页面来源并不是账单报告中可按页面汇总的标准维度。

要定位具体页面，可以采用以下方法：

按 API、SKU 和 API key 检查异常用量。
为不同页面或页面组配置不同的 API key。
通过网站分析或服务端日志记录地图组件的实际加载情况。
对 Places、Geocoding 等附加服务单独埋点，不能只统计地图页面的访问量。

为什么页面访问量和计费用量可能不一致

一次页面访问可能产生多次计费请求，具体费用取决于页面加载了哪些 Maps Platform 服务，例如：

加载 Maps JavaScript API 并创建地图。
使用 Places Autocomplete。
请求 Place Details。
调用 Geocoding、Directions 或 Distance Matrix 等 API。
页面局部刷新、组件重新挂载或单页应用路由切换，使地图再次初始化。
同一页面包含多个地图实例。
预加载、隐藏组件或第三方脚本在用户看到地图前就加载了 API。
API key 被其他页面、子域名或未授权网站使用。
服务端定时任务或后台程序使用了同一项目和凭据。

因此，不能直接根据”地图页面浏览量”推算账单请求数。应先在 Google Cloud Console 的 Billing 和 Google Maps Platform 指标中，按 SKU、API 和凭据进行核对。

推荐的排查步骤

1. 按 API 和 SKU 拆分用量

先确定费用来自哪项服务，不要只看项目的请求总数。重点检查：

Maps JavaScript API
Maps Static API
Street View Static API
Places API
Geocoding API
Directions API
Distance Matrix API

如果页面只展示普通地图，异常费用却来自 Places 或 Geocoding，问题通常出在页面中的搜索、地址解析或地点详情逻辑，而不是地图本身。

还需要检查 HTTP 错误、配额拒绝和异常流量。控制台中的指标并非都等同于可计费事件，最终应以账单中的 SKU 用量为准。

2. 检查 API key 限制

浏览器使用的 key 应设置网站限制，并尽量添加 API 限制。

例如，可以允许：

https://www.example.com/*
https://example.com/*
https://admin.example.com/*

同时，只允许该 key 调用实际需要的 API。

HTTP referrer 限制用于控制哪些域名和路径可以使用 key，但这不代表控制台会自动生成按 referrer URL 汇总的账单报告。限制规则也不要设置得过宽，例如：

https://*.example.com/*

如果只有一个子域名需要地图，应将范围限制在该子域名。

3. 为页面组分配不同的 API key

如果需要在 Google Cloud 指标中区分用量，可以按功能区域创建不同的 key，例如：

商品门店页：maps-store-pages
联系页面：maps-contact-page
后台管理：maps-admin
地点搜索：places-search

各页面根据功能选择相应的 key：

<script
  async
  src="https://maps.googleapis.com/maps/api/js?key=STORE_PAGES_KEY&callback=initMap">
</script>

联系页面则使用另一把 key：

<script
  async
  src="https://maps.googleapis.com/maps/api/js?key=CONTACT_PAGE_KEY&callback=initMap">
</script>

配置完成后，就可以按凭据查看和比较请求指标。这种做法适合定位页面组的问题，但不适合为数千个动态 URL 逐一创建 key。API key 数量、管理成本和项目配额可能有限，应根据当前 Google Cloud 项目的限制划分页面组。

Maps JavaScript API 的浏览器端 key 出现在页面源代码中属于正常情况。它的安全性依赖 HTTP referrer 限制和 API 限制，而不是隐藏 key。服务端使用的 key 不应发送到浏览器。

4. 记录地图实际初始化事件

页面浏览量无法准确反映地图的加载次数。可以在地图真正初始化时发送分析事件：

function initMap() {
  const mapElement = document.getElementById("map");

  if (!mapElement) {
    return;
  }

  const map = new google.maps.Map(mapElement, {
    center: { lat: 31.2304, lng: 121.4737 },
    zoom: 12
  });

  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: "google_map_initialized",
    page_path: window.location.pathname,
    map_id: mapElement.id
  });
}

如果使用自有统计接口，也可以记录页面路径和地图类型：

function recordMapUsage(component) {
  navigator.sendBeacon(
    "/analytics/map-usage",
    JSON.stringify({
      path: window.location.pathname,
      component,
      timestamp: new Date().toISOString()
    })
  );
}

应在地图或相关服务真正初始化的位置调用：

recordMapUsage("store_locator_map");

sendBeacon() 记录的只是网站侧事件，无法证明 Google 一定产生了相应的可计费 SKU，也不能代替 Google Cloud 的账单数据。它可以用来建立页面级统计，供后续对照。

5. 分别记录额外的 API 操作

如果页面使用 Places Autocomplete，除了地图初始化，还应记录用户选择地点后实际触发的操作：

autocomplete.addListener("place_changed", () => {
  const place = autocomplete.getPlace();

  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: "places_place_selected",
    page_path: window.location.pathname,
    has_place_id: Boolean(place.place_id)
  });
});

不要直接把地址、用户输入、坐标或完整地点信息发送到分析系统，除非已经评估过隐私、合规和数据保留要求。

对于服务端 Geocoding 等请求，可以在应用日志中记录调用来源：

logger.info("maps_api_request", {
  api: "geocoding",
  sourcePage: request.body.sourcePage,
  route: request.path
});

日志中不要记录完整的 API key。

旧站点中常见的重复加载问题

可以搜索代码中的所有 Maps 脚本引用，检查模板、插件和业务组件是否在同一页面重复加载脚本：

<script src="https://maps.googleapis.com/maps/api/js?..."></script>

尤其要检查以下情况：

公共布局模板已经加载一次，页面模板又加载了一次。
标签管理器或第三方插件额外注入 Maps 脚本。
SPA 组件每次挂载时都重新创建地图。
弹窗关闭后只隐藏 DOM，没有销毁相关监听逻辑。
Autocomplete 在重复渲染时被多次绑定。
开发、测试和生产环境共用同一个 API key。
页面预渲染或爬虫访问触发地图加载。

可以在浏览器开发者工具的 Network 面板中筛选：

maps.googleapis.com
maps.gstatic.com

然后重新加载页面、切换路由并操作地图，观察请求是否重复出现。Network 面板显示的是网络请求，不能把其中每一条资源请求都视为一次计费事件。是否计费仍取决于对应 SKU 的规则。

实际可行的统计方案

比较稳妥的做法是结合三类数据：

Google Cloud Billing：确认实际计费的 SKU 和金额。
Google Maps Platform 指标：按 API、凭据和时间查找异常来源。
网站分析及服务端日志：按页面路径记录地图和附加服务的初始化次数。

如果只想快速定位问题，可以先把网站划分成少量页面组，并为每组配置独立且受限的 API key。观察一个完整的业务周期后，通常可以判断异常用量集中在哪个功能区域。

如果需要精确到每个动态 URL，则要依靠网站自身的埋点或日志系统，因为 Google 的标准账单报告通常无法提供页面级归因。