永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么我们宁愿失去一笔生意，也不愿把限制藏在细则里
任何公司在编写自己的价格页面时，都有一条特定的、诱人的捷径：把好的部分醒目地展示出来，而让限制藏在脚注里、藏在三次点击之外的支持文章里，或者用足够含糊的措辞，让大多数读者以为是更宽松的解释。从狭义上讲，这确实有效，它带来的注册量比一个预先清楚说明每项限制的页面更多。它也会带来一个可以预见的后续代价：客户在集成过程中或在账单上吃了苦头才发现某个限制，从而感到被误导，而不是仅仅被告知。
我们宁愿接受清楚说明限制所带来的较少注册量，也不愿接受让人们在没有完全了解自己会得到什么的情况下注册所带来的较多注册量。免费配额是每天 2,500 次请求，按网络计算，并由该网络的无密钥使用和有密钥使用共享。对于评估和小规模使用来说，这是一个确实有用的数字，同时它显然也是一个限制。直接说出这一点，而不是强调“免费”、把上限留给别人通过失败的请求去发现，是一种在短期内会让我们付出代价的诚实。
只有当您纯粹用注册数量衡量成功时，这种取舍才显得不划算。以整个客户关系的生命周期来衡量，情况就不同了。一个在承诺之前就了解限制、仍然选择继续的客户，以后不会感到意外或被欺骗，因为从注册到真正达到阈值的那一刻，他们的情况没有任何改变。一个在较为含糊的印象下注册、然后在真实上限影响到自己时才发现的客户，有正当的不满，而正当的不满会变成公开投诉、退款请求和声誉损失，其持续时间比造成这些不满的那次注册的价值更长久。
同样的逻辑也解释了为什么配额响应头存在于每个响应中，而不仅仅在账户控制台里；为什么速率限制在文档中以真实数字公布，而不是含糊地描述；以及为什么 Unlimited 密钥真的是无限的，而不是带有未公开软上限的“无限”。在这些地方，更含糊、听起来更慷慨的版本在第一印象上的转化率可能会略高一些，而我们仍然选择了诚实的版本。
我们并不认为这让我们格外高尚。它更像是一种押注：什么样的公司能够经受住客户多年来大规模实际使用产品的考验，而不只是注册一次。一个纯粹为最大化注册量而优化的价格页面把注册当作终点线。我们认为注册更接近起跑线，而您没有读到的小字，恰恰是这段关系中决定注册之后的岁月是否顺利的那部分。