在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
缓存地理编码结果，又不打乱您的配额计算
在一周内对同一地址进行两次地理编码是很常见的情况，而缓存是显而易见的解决办法。容易让人犯错的地方在于忘记：缓存命中和缓存未命中在您的应用看来完全相同，但对您的配额来说却截然不同。
哪些内容可以安全缓存
已完成地理编码的地址很少变化，因此以规范化后的输入为键，缓存正向或逆向查询的完整结果，可以安全地保存很长时间，视您的地址数据变动程度而定，可以是数周或数月。IP 查询结果可以安全缓存的时间较短，因为 IP 段偶尔会被重新分配。时区查询返回的标识符是稳定的，但其 utc_offset 会随夏令时而变化，因此应缓存标识符并重新计算偏移量，而不是无限期地缓存整个响应。
从缓存提供结果不会消耗配额
缓存命中意味着您对该请求根本没有调用 API，因此 X-Quota-Used 和您的额度余额都不会有任何变化。这正是缓存的全部意义所在，但这也意味着缓存命中不会出现在配额响应头中的任何地方，因为这些响应头只反映实际到达 API 的调用。除非您同时单独记录缓存命中，否则不要试图用配额响应头来核对您自己的请求计数。
缓存键示例
cache_key = "forward:" + normalize("221B Baker Street, London")在计算哈希之前先进行规范化：转为小写、去除首尾空白、合并连续空格，这样输入中细微的格式差异就不会造成不必要的缓存未命中。
预估规模
如果在缓存有效期内，您收到的地址有一半是重复的，那么您实际消耗免费配额和预付额度的请求数大约只有原始地址量的一半。在决定是否需要超出每个密钥附带的每天 2,500 次免费请求而升级之前，了解这一点很有价值，因为真正到达 API 的请求数可能远低于原始流量所显示的数字。
何时绕过缓存
对于任何过期结果会导致明显错误的情况，都应跳过缓存，例如重新验证客户刚刚更正的地址。一次全新的查询无论如何都只消耗一次请求，因此针对特定更正绕过缓存，是防止提供已知错误的缓存结果的一种低成本保障。
做好缓存，关键在于了解哪些字段是稳定的、哪些不是，而不是要么全部缓存、要么完全不缓存。有关适合用作缓存键的字段，请参阅正向地理编码文档。