优化指南
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本指南从安全性、性能和消耗三个方面介绍了优化 Google 地图各 API 用量的几种策略。
安全性
查看安全性最佳实践
API 密钥是以项目为中心的凭据，为其采取的预防措施应与用户 ID 和密码相同。请参阅 API 安全性最佳实践来保管您的密钥，以防误用。误用可能会导致配额过度使用，使您的账号产生意外费用。
使用 API 密钥访问 Google 地图的各个 API
API 密钥是访问 Google 地图各 API 的首选身份验证方法。虽然目前仍支持使用客户端 ID 进行身份验证，但 API 密钥支持更精细的安全控制措施，并且经过调整后可与特定网址、IP 地址和移动 SDK（Android 和 iOS）配合使用。如需了解如何创建及保管 API 密钥，请前往各个 API 或 SDK 所对应的“使用 API 密钥”页面。例如，如果您使用的是 Maps JavaScript API，请访问该 API 对应的使用 API 密钥页面。
使用指数退避算法处理错误
如果应用因短时间内尝试调用 API 的次数过多而出现错误（如配额错误），请考虑使用指数退避算法来处理请求。指数退避算法最适合处理 500 系列错误。
具体而言，您可以调整查询的节奏。在代码中，在查询之间添加 S 秒的等待期。如果查询仍导致配额错误，请将等待期延长一倍，然后再发送另一个查询。您可以不断调整等待期，直到查询不再返回错误为止。
按需发送用户互动请求
您应仅按需向 API 发送包含用户互动的请求。也就是说，您需要等到最终用户执行某项操作（例如 on-click）后再发起 API 请求，然后根据结果来加载地图、设置目的地或显示适当的信息。采用这种按需发送的方法可避免向 API 发出不必要的请求，从而减少 API 消耗。
避免在地图移动时显示叠加层内容
如果用户正在移动地图，请不要使用 Draw() 方法在地图上显示自定义叠加层内容。每次用户移动地图时，系统都会重新绘制地图，此时如果在地图上放置叠加层内容，可能会导致延迟或视觉卡顿。请仅在用户停止平移或缩放后，才在地图上添加或从中移除叠加层内容。
避免在 Draw 方法中执行密集型操作
一般来说，最好不要在 Draw() 方法中执行对性能要求较高的非绘制操作。例如，请避免在 Draw() 方法的代码中执行以下操作：
- 使用会返回大量内容的查询。
- 对当前显示的数据进行多项更改。
- 处理多个文档对象模型 (DOM) 元素。
这些操作可能会降低性能，并在渲染地图时造成延迟或视觉卡顿。
使用光栅图片作为标记
在地图上添加标记来标识位置时，请使用光栅图片，例如 .PNG 或 .JPG 格式的图片。请不要使用可缩放矢量图形 (SVG) 格式的图片，因为在重新绘制地图时，渲染 SVG 图片可能会导致延迟。
优化标记
您可以将多个标记渲染为单个静态元素，从而对标记进行优化，以提高性能。在需要大量标记的情况下，这种方法非常实用。默认情况下，Maps JavaScript API 会决定是否优化标记。如果存在大量标记，Maps JavaScript API 会尝试在渲染标记时对标记进行优化，但并非所有标记都可以优化。有时，Maps JavaScript API 可能需要在不优化标记的情况下渲染标记。如果您使用了动画 GIF 或 PNG，或者必须将每个标记渲染为单独的 DOM 元素，请停用优化型渲染。
创建聚类来管理标记显示
为方便管理标记（用于在地图上标识位置）的显示，您可以使用标记聚类器库来创建标记聚类。标记聚类器库包含以下选项：
- 网格大小：用于指定要组合到一个聚类中的标记数量。
- 最大缩放级别：用于指定显示该聚类时可达到的最大缩放级别。
- 图片路径：用于指定要用作标记图标的图形图片。
消耗
如需了解如何管理 Google Maps Platform 费用，包括创建预算、修改配额和设置提醒，请参阅管理费用。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-31。
[null,null,["最后更新时间 (UTC)：2025-08-31。"],[[["\u003cp\u003eThis guide provides strategies for optimizing Google Maps APIs usage, focusing on security, performance, and cost management.\u003c/p\u003e\n"],["\u003cp\u003eSecure your API keys by reviewing security best practices and using them as the preferred authentication method.\u003c/p\u003e\n"],["\u003cp\u003eImprove performance by utilizing techniques like exponential backoff for error handling, sending user-interaction requests on demand, and optimizing marker display.\u003c/p\u003e\n"],["\u003cp\u003eManage costs by setting budget alerts, capping daily API usage, and strategically using different Google Maps Platform products based on your needs.\u003c/p\u003e\n"],["\u003cp\u003eUnderstand Google Maps Platform quotas and how they apply to your API usage to avoid unexpected limitations.\u003c/p\u003e\n"]]],["Optimize Google Maps APIs usage by securing API keys, using them instead of client IDs, and implementing exponential backoff for errors. Enhance performance by sending requests on demand, avoiding overlays during map movement, using raster images for markers, and optimizing/clustering markers. Control consumption by setting budget alerts, capping daily usage, using static images when user interaction isn't needed, using the embed API for basic maps, and using mobile SDKs for mobile. In addition, you can reduce costs with optimized routing, limited waypoints, and cost-effective autocomplete and geocoding options.\n"],null,["# Optimization Guide\n\nThis guide describes several strategies to optimize your Google Maps APIs\nusage in terms of security, performance, and consumption.\n\nSecurity\n--------\n\n### Reviewing security best practices\n\nAPI keys are project-centric credentials that deserve the same precautions\nas user IDs and passwords. Review the\n[API Security Best Practices](/maps/api-security-best-practices) to secure your keys from\nunintended use which could lead to undue quota usage and unexpected charges\nto your account.\n\n### Using API keys to access Maps APIs\n\nAPI keys are the preferred authentication method for accessing\nGoogle Maps APIs. While using the client IDs is still\nsupported, API keys support finer-grained security controls and can be tuned to\nwork with specific web addresses, IP addresses, and mobile SDKs (Android and\niOS). For information on creating and securing an API key, go to the \"Using an\nAPI Key\" page for each API or SDK. (For example, for the\nMaps JavaScript API, visit its page on [Using an API\nKey](/maps/documentation/javascript/get-api-key).)\n\nPerformance\n-----------\n\n### Using exponential backoff to handle errors\n\nIf your apps experience errors from excessive attempts to call an API\nwithin a short period of time, such as quota errors, consider using\n[exponential backoff](http://en.wikipedia.org/wiki/Exponential_backoff) to let the requests process.\nExponential backoff is most useful for errors in the 500s.\n\nSpecifically, adjust the pace of your queries. In your code, add\na waiting period of **`S`** seconds between queries. If the query still results\nin a quota error, double the waiting period and then send another query. Continue\nadjusting the waiting period until the query returns without an error.\n\n### Sending user-interaction requests on demand\n\nRequests to APIs that include user interaction should be sent only on demand.\nThis means waiting for the end user to perform an action (such as `on-click`)\nto initiate the API request, then using the results to load a map, set a\ndestination, or display appropriate information. Using an on-demand approach\navoids unnecessary requests to the APIs, reducing API consumption.\n\n### Avoiding displaying overlay content when a map is moving\n\nAvoid using `Draw()` to display custom overlay content on a map at the same\ntime that a user might be moving the map. Since the map is redrawn every time\na user moves the map, placing overlay content on the map at the same time can\nintroduce lag or visual stuttering. Only add or remove overlay content from a\nmap once the user stops panning or zooming.\n\n### Avoiding intensive operations in `Draw` methods\n\nAs a general rule, it is good practice to avoid performance-intensive\nnon-drawing operations in a `Draw()` method. For example, avoid\nthe following in your `Draw()` method code:\n\n- Queries that return a large amount of content.\n- Many changes to the data being displayed.\n- Manipulating many Document Object Model (DOM) elements.\n\nThese operations can slow performance and introduce lag or visual stuttering\nwhen the map renders.\n\n### Using raster images for markers\n\nUse raster images, such as images in .PNG or .JPG format, when adding\nmarkers to identify a location on a map. Avoid using Scalable Vector\nGraphics (SVG) images, since rendering SVG images can introduce lag when\nthe map is redrawn.\n\n### Optimizing markers\n\nOptimization enhances performance by rendering many markers as a single static\nelement. This is useful in cases where a large number of markers is required.\nBy default, the Maps JavaScript API will decide whether a marker\nwill be optimized. When there is a large number of markers, the\nMaps JavaScript API will attempt to render markers with\noptimization. Not all Markers can be optimized; in some situations, the\nMaps JavaScript API may need to render Markers without\noptimization. Disable optimized rendering for animated GIFs or PNGs, or when\neach marker must be rendered as a separate DOM element.\n\n### Creating clusters to manage marker display\n\nTo help manage the display of markers to identify locations on a map,\ncreate a marker cluster using the\n[Marker Clusterer](https://github.com/googlemaps/js-marker-clusterer) library.\nThe Marker Clusterer library includes options for:\n\n- Grid size, to specify the number of markers to group together in a cluster.\n- Maximum zoom, to specify the maximum zoom level in which to display the cluster.\n- Image paths, for the graphics images to use as marker icons.\n\nConsumption\n-----------\n\nFor information on managing your Google Maps Platform costs, including\ncreating budgets, modifying quotas, and setting alerts, see\n[Manage costs](/maps/billing-and-pricing/manage-costs)."]]
