Google Places API首次使用触发OVER_QUERY_LIMIT错误求助

遇到这个问题确实挺头疼的，尤其是刚配置完第一次用就碰上限额。结合你描述的场景——刚创建Google Cloud项目、启用Places API并限制了密钥用途，我整理了几个最可能的原因和对应的解决办法：

1. 配额激活存在延迟 #

Google Cloud的API配额并不是即时生效的，当你刚启用Places API并创建密钥后，系统需要一点时间（通常15-30分钟）来完成配额的分配和同步。如果是刚配置完就立刻测试，很可能系统还没把基础配额加载到你的项目里，导致请求直接触发限额。

解决办法：先暂停测试，等待20-30分钟后再尝试发起请求，大部分情况下这个问题会自动消失。

2. API密钥的限制配置有误 #

虽然你设置了密钥仅用于Places API，但如果附加的平台限制（比如Android的包名/SHA-1、iOS的Bundle ID）配置错误，请求会被视为未授权的匿名请求——而匿名请求的配额极低（通常只有几次），很容易就触发OVER_QUERY_LIMIT。

检查要点：

• 确认密钥绑定的是你刚创建的正确项目，且Places API确实处于启用状态（在Cloud Console的API库中可以验证）。
• 对于Android调试环境：用keytool -list -v -keystore ~/.android/debug.keystore（默认密码是android）获取调试SHA-1指纹，对比Cloud Console中密钥的限制配置是否完全一致，包名也要和Flutter项目android/app/build.gradle里的applicationId匹配。
• 对于iOS：检查Cloud Console中配置的Bundle ID是否和Xcode项目里的Bundle Identifier完全一致。

3. 误使用了旧的/错误的API密钥 #

有可能你复制API密钥的时候不小心用了其他项目的密钥——比如之前测试用过的旧密钥，而那个项目的Places API配额已经耗尽了。

解决办法：重新从Cloud Console中复制刚创建的API密钥，替换Flutter项目中的配置，确保没有复制错误（注意不要包含多余的空格或换行）。

4. 查看实际配额消耗情况 #

你可以直接在Google Cloud Console的Places API配额页面，查看当前的配额额度和已消耗的请求数：

• 如果显示已消耗的请求数远高于你实际发起的次数，可能是代码中存在重复请求的逻辑（比如Autocomplete的回调被多次触发）。
• 如果显示配额额度为0或远低于预期的数千次，可能是系统分配延迟，或者需要手动确认配额是否正常加载（可以尝试禁用再重新启用Places API）。

内容的提问来源于stack exchange，提问作者nick.tdr