调用Google Places API数次后失效，次日恢复，报Api Exception 10/13

我之前也碰到过类似的Google Places API抽风问题，太闹心了！结合踩过的坑，给你整理几个排查方向：

先明确下这两个错误的常见含义：

• Api Exception 10：通常是API密钥无效或未正确配置（比如密钥绑定的包名/签名不对，或者没启用Places API）
• Api Exception 13：一般关联权限/配额限制，但你说查过配额，那得往其他细节方向挖

1. 先确认API密钥的实时有效性 #

虽然你查过配额，但有时候密钥配置会有延迟，或者不小心改了绑定信息：

• 去Google Cloud控制台，检查Places API是否真的处于启用状态（有时候会被误关）
• 核对密钥绑定的应用包名+SHA-1签名，尤其是debug和release签名是否都添加了——很多人只加了release，调试时用debug签名就会触发报错
• 试试直接在浏览器里用你的密钥调用Places测试接口（比如https://maps.googleapis.com/maps/api/place/textsearch/json?query=restaurant&key=你的密钥），看返回是否正常，先排除应用端的问题

2. 排查请求频率与突发限流 #

即使配额没超，Google API有突发请求限制（短时间内大量请求会被临时限流），调试时反复调用很容易触发：

• 检查代码里是否有重复调用、循环请求的逻辑，比如页面刷新就重复发起请求
• 试试在请求之间加1-2秒的短暂延迟，看是否还会出现后续调用失效的情况
• 去Cloud控制台的API监控里看请求日志，有没有被标记为"限流"的记录——有时候配额没超但限流了，不会在配额页面直接显示

3. 检查应用端的API客户端配置 #

有时候是客户端的问题导致请求异常：

• 确认你用的Places SDK版本是否兼容，旧版本可能存在bug，试试升级到最新稳定版
• 检查请求参数是否正确，比如是否遗漏了必要参数（如location、radius），或者参数格式错误（比如radius值超出范围）
• 排查网络层面的问题，比如调试设备的网络是否不稳定，或者代理/防火墙拦截了请求（尤其是企业网络环境）

4. 临时缓存与重试机制（应急方案） #

针对这种偶尔恢复的情况，可以在代码里加个简单的重试逻辑应急：

// 示例：Java中的重试逻辑
int retryCount = 0;
PlaceResult result = null;
while (retryCount < 3) {
    try {
        result = placesClient.fetchPlace(request).await();
        break;
    } catch (ApiException e) {
        if (e.getStatusCode() == 13 && retryCount < 2) {
            retryCount++;
            Thread.sleep(1000); // 延迟1秒后重试
        } else {
            throw e;
        }
    }
}

不过这只是临时 workaround，还是得找到根本原因才行

如果以上方法都试过还是不行，建议去Google Cloud的支持中心提交工单，附上你的请求日志和密钥配置截图，官方能查到更详细的错误原因。

内容的提问来源于stack exchange，提问作者Rufus