优化网络服务用量
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
重要提示：Google Maps Platform 专业版方案不再开放注册，也不再提供给新客户。
概述
如果您的应用超出 Google Maps Platform 网络服务的用量限额，服务将返回错误消息。如果您的应用持续超出用量限额，系统可能会阻止其访问网络服务，在某些情况下，您的应用会收到“403 Forbidden”响应。
如果应用的网络服务请求收到错误消息，您可以通过优化应用来更高效地使用网络服务，从而降低使用量。
准备工作
在优化应用的网络服务用量之前，请检查您是否为用例使用了正确的服务，以及使用的 Maps API 许可是否正确。
验证您的用例
Google Maps Platform 网络服务最适合不需要实时输入的应用
或未使用网络浏览器的情况例如，如果您的
应用使用独立于用户输入的数据集，例如固定的
需要进行地理编码的房地产网站上的地址。
请注意，使用网络服务时，每分钟查询 (QPM) 限制适用于
专业版方案许可，不考虑有多少个 IP 地址
发出请求
另一方面，系统会按浏览器会话对通过 Maps JavaScript API 提供的客户端服务设置速率限制，如此一来，请求便会分布于所有用户中，并会随用户数量的增长而扩展。因此，客户端服务最适合实时对用户输入的地址进行地理编码的应用，例如供用户搜索家庭住址附近商店的店铺定位工具。
如需详细了解何时使用网络服务，请参阅地理编码策略。尽管该文档专门针对地理编码，但其中的建议适用于所有网络服务。该文档说明了何时应使用服务器端网络服务以及何时应使用客户端网络服务。
如何优化网络服务用量
为了更高效地使用网络服务，您可以通过以下两种方式降低用量：1) 仅在需要时发送请求；2) 均衡使用网络服务，不超过用量限额。
缓存结果
《Google Maps Platform 服务条款》第 3.2.3.a 和 b 条规定，除了条款中规定的符合有限条件的内容之外，您不得预先提取、存储、缓存任何内容以及将其编入索引。
请注意，用于唯一标识地点的地点 ID 可不受缓存限制。因此，您可以无限制地存储地点 ID 值。
限制请求数量
如要避免超出用量限额，您可以将应用配置为限制请求数量，具体方法是将请求置于可跟踪其发送时间的队列中。如果您的应用
收到一个超出 QPM 限制的额外请求，请调整查询速度。在代码中，在两次查询之间添加 **`S`** 秒的等待期。如果查询仍然导致配额错误，请将等待期延长一倍，然后发送另一个查询。继续调整等待期，直到查询不再返回错误为止。
即使进行了限制，应用可能仍会收到状态代码为 OVER_QUERY_LIMIT 的响应。请配置您的应用以插入短暂延迟（20 毫秒），如果应用收到此类响应，请再试一次。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-31。
[null,null,["最后更新时间 (UTC)：2025-08-31。"],[[["\u003cp\u003eThe Google Maps Platform Premium Plan is no longer available for new customers.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Maps Platform web services are best suited for applications with non-real-time data and fixed datasets, like geocoding addresses on a real estate website.\u003c/p\u003e\n"],["\u003cp\u003eClient-side services, like the Maps JavaScript API, are recommended for applications requiring real-time user interaction, such as store locators.\u003c/p\u003e\n"],["\u003cp\u003eOptimize web service usage by caching allowed data like place IDs and throttling requests to stay within usage limits.\u003c/p\u003e\n"],["\u003cp\u003eIf exceeding usage limits, adjust request frequency and incorporate delays to prevent service disruptions and errors.\u003c/p\u003e\n"]]],[],null,["**Important:** The Google Maps Platform Premium Plan is no longer available for\nsign up or new customers.\n\nOverview\n\nIf your application exceeds the usage\nlimits for a Google Maps Platform web service, the service returns an error message. If your\napplication continues to exceed the usage limits, it might be blocked from accessing the\nweb service and, in some cases, receive \"403 Forbidden\" responses.\n\nIf your application's web service requests receive error messages, you can lower usage by\noptimizing applications to use the web services more efficiently.\n\nBefore you begin\n\nBefore optimizing your application's web service usage, check that you're using the correct\nservice for your use case and the correct Maps APIs license.\n\nValidate your use case\n\nGoogle Maps Platform web services are best for applications that don't require real-time input\nfrom users or when a web browser is not used. For example, you should use web services if your\napplication uses a dataset that is independent of user input---for example, a fixed set\nof addresses on a real estate website that needs to be geocoded.\n\nNote that with web services, the queries-per-minute (QPM) limit applies to your\nPremium Plan license, regardless of how many IP addresses\nrequests are sent from.\n\nOn the other hand, the client-side services available with the Maps JavaScript API\nare rate limited per browser session, so that requests are distributed across all your users and\nscale as the number of users grows. Therefore, client-side services are best for applications\nthat geocode address input from users in real time, such as a store locator that searches for\nstores near a user's home address.\n\nFor a more detailed discussion on when to use web services, see [Geocoding\nStrategies](/maps/documentation/geocoding/geocoding-strategies). Although specific to geocoding, the recommendations in this\ndocument apply to all web services, explaining when you should use server-side\nweb services or their client-side equivalents.\n\nHow to optimize web service usage\n\nTo use web services more efficiently, you can lower usage by sending requests only when\nnecessary and spreading usage evenly to keep it under the limits.\n\nCache results\n\nSections [3.2.3.a and b](https://cloud.google.com/maps-platform/terms/#3.-license.)\nof the Google Maps Platform Terms of Service states that you must not pre-fetch, index, store, or cache any Content\nexcept under the limited conditions stated in the Terms.\n\nNote that the **place ID** , used to uniquely identify a place, is **exempt\nfrom** the caching restriction. You can therefore store place ID values indefinitely.\n\nThrottle requests\n\nTo avoid exceeding usage limits, you can configure your application to throttle requests, by\nplacing them in a queue that keeps track of when the requests are sent. If your application\nreceives one additional request beyond the QPM limit, adjust the pace of your queries. In your code, add a waiting period of \\*\\*\\`S\\`\\*\\* seconds between queries. If the query still results in a quota error, double the waiting period and then send another query. Continue adjusting the waiting period until the query returns without an error.\n\nEven with throttling, applications might still receive responses with the status code\n`OVER_QUERY_LIMIT`. Configure your application to insert a small delay (20 ms)\nand try again if it receives such response."]]
