永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
隐藏您真实用量的控制台带来的问题
用量控制台本应随时回答一个简单的问题：我现在处于什么状况。然而许多控制台回答的却是一个略有不同的问题：截至我们的计费系统上次核对用量时，您处于什么状况。那可能是一小时前，可能是今天早上，而在流量高峰期间，正是这段时间差会把一个可控的局面变成一笔意外的超额费用，或者一份意外耗尽的免费配额。
我们认为，把控制台作为这类信息唯一的可信来源是不对的，这并不是因为控制台不好，而是因为控制台天生就与真正重要的那个请求隔了一层。对该具体请求的响应，才是唯一保证反映您在那个确切时刻确切状况的地方，因为它与请求本身被计数是同时生成的。这就是为什么 My Geocode 的每个响应都直接带有配额响应头：您的限额、已使用量、剩余免费配额、您所在网络的用量、剩余预付额度，以及配额重置的时间。您不必另开一个标签页，然后祈祷它已经同步到最新。
这一点在滞后的控制台最容易失灵的情况下最为重要：流量突然激增、某个批处理任务迅速消耗掉一大块配额，或者某个发布日的用量与平常截然不同。一个存在延迟的控制台，会在真实数字早已变得紧迫之后，依然长时间显示一个令人安心的数字。而您刚刚收到的实际响应中的响应头，不会以同样的方式滞后，因为它们不是一个努力追赶进度的独立报告系统。它们是作为响应请求本身的一部分而生成的。
控制台作为查看长期趋势、回顾历史记录或管理不会随每次请求而变化的账户详情的地方，仍然具有真正的价值。我们并不是主张控制台不应存在。我们主张的是，它不应成为开发者了解自己是否即将耗尽配额或额度的唯一地方，或主要地方。这些信息需要在可以据以采取行动的时刻提供，也就是请求发生的那一刻，而不是等到控制台自身的刷新周期轮到反映它的某个稍后时刻。
滞后的控制台更深层的问题在于，它可能制造一种虚假的安全感，这比完全没有可见性还要糟糕。一个查看控制台、看到令人安心的数字、然后满怀信心继续推进的开发者，恰恰被一个本应防止这种结果的工具主动误导了。响应本身携带的实时信息则完全避开了这个陷阱，因为不存在一个需要先考虑其数据是否过时、才能信任其数字的独立系统。