在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
无需编写循环即可对一组坐标进行逆地理编码
如果您有一张经纬度坐标对的表，以及一个每行调用一次 API 的脚本，那么您付出的代价是往返通信，而不是查询本身。逆地理编码端点与正向端点一样接受批量 POST 请求体，在一次调用中解析所有坐标对。
发送坐标对
不要为每个点发送一次 GET 请求，而是向 /v1/reverse 发送一个坐标对象数组。每一项都会按提交顺序返回各自的地址。
POST /v1/reverse
Content-Type: application/json
[{"lat": 48.8584, "lon": 2.2945}, {"lat": 40.6892, "lon": -74.0445}]{
"status": "ok",
"results": [
{"formatted": "Champ de Mars, Paris, France", "lat": 48.8584, "lon": 2.2945, "type": "address", "precision": "street", "confidence": 0.9, "place_id": "gh789", "components": {}},
{"formatted": "Liberty Island, New York, NY", "lat": 40.6892, "lon": -74.0445, "type": "address", "precision": "street", "confidence": 0.88, "place_id": "jk012", "components": {}}
]
}为什么这比循环更好
每个坐标发起一次 HTTP 请求的循环，会为每一行增加连接开销，也让您更难把握每日配额，因为您看到的是数百个独立响应的响应头不断滚动，而不是一个。一次批量调用仍然按每项一次请求计费，因此相对于配额的总成本完全相同，但您只需读取一组配额响应头，也只需在一个地方捕获错误。
读取响应
数组中的每个结果都与您在相同位置发送的坐标一一对应。如果某个点落在附近没有地址的地方，例如开阔水域或大片未测绘区域，预计会得到较低的置信度分数或较粗的精度值，而不是错误，因此在将格式化地址用于任何面向客户的场景之前，请检查这两个字段。
第二个例子：与时区数据配合使用
拿到坐标列表对应的地址之后，一个常见的后续需求是查出每个位置当前的时间。与其再循环一遍结果，不如把同一个坐标列表作为单独的批量请求传给 /v1/timezone。最终您会得到两个对齐的数组：来自 /v1/reverse 的地址和来自 /v1/timezone 的时区标识符，都保持原始的行顺序，费用为每个端点每个点一次请求。
值得避免的错误
不要在发送之前就假设表中的每个坐标都有效。纬度超出 -90 到 90 或经度超出 -180 到 180 的范围（在电子表格中列被互换时，这种情况比应有的更常见），即使无法返回合理的结果，仍然会计为一次请求。请在批次发出之前，在您自己的代码中检查数值范围，而不是为一个注定不会成功的查询付费。
确定批次大小
无需在一次请求中发送整张数据库表。根据您自己脚本的内存和超时限制，将坐标分组成合适大小的批次，并记录每个批次从每日免费配额或额度余额中使用了多少次请求。每个响应中的 X-Quota-Used 和 X-Quota-Free-Remaining 响应头会在您发送下一批之前准确告诉您当前的状态。
以这种方式对整个列表进行逆地理编码，可以把过去缓慢的循环变成每批一次请求，而 API 对每一项所做的工作在两种方式下都是一样的。完整的请求和响应说明见逆地理编码文档。