最佳化網路服務使用情形
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
重要事項：Google 地圖平台付費方案不再開放註冊或提供給新客戶。
總覽
當您的應用程式用量超過 Google 地圖平台網路服務的用量限制，系統就會傳回錯誤訊息。如果持續超出限制，應用程式可能會遭到封鎖，而無法存取網路服務，在某些情況下甚至會收到「403 禁止」回應。
如果應用程式的網路服務要求收到錯誤訊息，不妨提高應用程式使用網路服務的效率，藉此降低用量。
事前須知
在將應用程式的網路服務使用情形進行最佳化之前，請先確認您已根據用途需求，選用合適的服務及正確的 Maps API 授權。
確認用途需求
Google 地圖平台網路服務最適合不需要即時輸入資料的應用程式
或是沒有網路瀏覽器的情況下發生舉例來說，如果您的
應用程式會使用與使用者輸入內容無關的資料集，例如固定的集合
需要進行地理編碼的房地產網站上地址
請注意，使用網路服務時，每分鐘查詢次數 (QPM) 限制適用於
付費方案授權 (無論 IP 位址數量為何)
另外，Maps JavaScript API 用戶端服務的每瀏覽器工作階段也有頻率限制，因此系統會在所有使用者之間平均分配可傳送的要求數，並隨著人數增長來調整資源配置。基於上述原因，會由使用者即時輸入地理編碼地址的應用程式最適合採用用戶端服務，例如可讓使用者搜尋自家地址附近門市據點的店家搜尋器。
如需網路服務適用時機的詳細介紹，請參閱地理編碼策略。雖然上文是以地理編碼為例，但本文件中提供的相關建議也適用於所有網路服務，其中會說明適合採用伺服器端及用戶端網路服務的時機。
如何將網路服務使用情形最佳化
如要提升網路服務的使用效率，您可以只在有需要時才傳送要求，並平均分配用量以免超過限制，藉此減少整體用量。
快取結果
根據《Google 地圖平台服務條款》第 3.2.3.a 和 b 節的規定，您不得對任何「內容」預先擷取、建立索引、儲存或快取，但如果符合「條款」中所述的少數條件則不受此限。
請注意，用於識別地點的地點 ID 不受快取限制的約束，因此您可以無限期儲存地點 ID 值。
調節要求數
為避免超出用量限制，您可以設定應用程式，將要求排入佇列以掌握要求傳送時間，藉此調節要求數量。如果您的應用程式
會收到一項超過 QPM 限制的額外要求，請調整查詢速度。在程式碼中新增每次查詢的間隔等候時間 (**`S`** 秒)。如果還是導致查詢發生配額錯誤，請將等候時間延長一倍，再傳送另一項查詢。繼續調整等候時間，直到查詢未傳回錯誤為止。
即使已有調節限制，應用程式仍可能會收到狀態碼為 OVER_QUERY_LIMIT 的回應。您可以將應用程式設為在收到這類回應時，先稍微延遲 (20 毫秒) 再重試。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-31 (世界標準時間)。
[null,null,["上次更新時間：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."]]
