永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么我们按项目而不是按调用计算批量请求
一个在一次调用中接受一千个地址、却只从您的配额中计为一次请求的批量端点，在价格页面上看起来很慷慨。但它并不慷慨。它是一个迟早会变成容量问题的舍入误差，因为这次调用背后的实际工作，也就是一千次单独的查询，并不会因为它们装在一个信封里到达就减少。
我们计算批量和大宗请求的方式与计算其他一切相同：一项，一次请求。如果您在一次批量调用中发送一千个地址，那就会从您的免费额度或预付额度中计为一千次请求，与您分别调用端点一千次完全一样。批处理带来的便利，即更少的往返次数和更低的连接开销，是真实的，也值得拥有。但查询本身的成本并不会因为您把它们放在一起请求而改变。
把批量调用的价格人为压低，会造成一种奇怪的扭曲。它奖励的是纯粹为了省钱而围绕大批量调用重构集成，而不是因为批量处理真正适合您的工作流程。它还让外界更难判断服务商实际的容量规划，因为“请求”不再代表一致的工作量单位。如果一家服务商的一个请求可能暗中包含一千次查询，而另一家的并不包含，那么按每天请求数比较服务商的客户就无法做出公平的比较。
按条目计数还能让我们的配额响应头保持意义。每个响应都会携带您已用量和剩余量的计数，而只有当一个请求无论以何种形式发送都算作一个请求时，这个数字才有意义。如果一个包含一千个条目的批量请求悄悄只算一个单位，这些响应头几乎无法告诉您真实的用量，而您只有在规模大得多的非批量用量撞上一个意料之外的限制时，才会发现真实的数字。
这里还有一个公平性的理由。逐个发送调用的客户和批量发送的客户，是在以相同的总价让我们完成相同的总工作量。仅仅因为请求被打包在一起，就向批量客户收取更低的单次查询费用，就意味着逐个调用的客户实际上在补贴并非由他们造成压力的基础设施。对两者按每次查询收取相同费用，价格就与工作量挂钩，而不是与工作量的打包方式挂钩。
这一切并不意味着批量处理没有意义。对于一组已知的大量查询，一次往返发送仍然是正确的方式，我们支持它，是因为更少的连接和更低的开销对您来说是实实在在的效率提升。批量处理不应该做的，是在请求的任何一方改变这些查询的实际成本。一千次查询就是一千次查询，无论它们是在一个下午里逐个到达，还是在一次调用中一起到达。