在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
在查询没有返回结果时设置备用方案
一个成功返回但其中没有任何有用结果的请求很容易被错误处理，因为在 HTTP 层面它看起来并不像失败，只是没有您期望的答案。
空结果是什么样子
对过于模糊或完全虚构的内容进行正向地理编码搜索，会返回 200 状态和一个空的 results 数组，而不是错误代码。
GET /v1/forward?q=xyzzy nonexistent place&limit=1{
"status": "ok",
"query": "xyzzy nonexistent place",
"results": []
}对未分配或私有地址段中的地址进行 IP 查询，会返回 found: false 而不是错误，同时附带它仍能填充的字段。
{
"status": "ok",
"ip": "10.0.0.5",
"version": 4,
"found": false
}构建明确的备用路径
请在代码中把空的 results 数组或 found: false 作为一个独立分支来检查，与成功路径以及针对 4xx 和 5xx 响应的错误处理路径分开。要有意识地决定接下来怎么做：请用户细化输入，退回到使用更高 limit 的更宽泛搜索，或者显示清晰的“未找到位置”消息，而不是一片空白或具有误导性的默认值。
值得首先排查的常见原因
地点确实不存在是原因之一，但格式不佳的输入字符串、拼写错误，或者意外混用了多种语言或文字的查询，也可能导致一个实际存在的地址返回空结果。在断定该位置本身不存在之前，请考虑对输入进行规范化，或者尝试设置 countries 参数的版本，是否能解决问题。
单独记录空结果
请独立于错误率，单独跟踪您的集成进入空结果路径的频率。空结果比例上升，往往说明上游存在数据质量问题，出在地址的收集或格式化方式上，而不是查询本身出了问题。
无结果查询的费用
空结果仍然计为一次请求，与成功匹配相同，因为无论结果如何，查询都已执行。对于返回空结果的查询，没有单独的折扣费率。
把空结果当作一种经过深思熟虑的独立结果来对待，而不是事后附加到错误处理上的补丁，会让集成明显更加稳健。错误页面介绍实际的错误响应，而空结果则与各端点的正常响应结构一起记录在文档中，例如正向地理编码文档。