为什么免费支持层级也应该得到真正的答复
一个只给付费客户深思熟虑的答复的支持队列，等于在告诉免费用户，他们的问题不值得认真解决。
永不过期的 API 密钥带来的问题
永不过期的密钥之所以方便，恰恰在于它让人很容易忘记它的存在。它只生成一次，嵌入某个配置文件或环境变量中，然后就一直无限期地正常工作，没有人再去审视它是否还应该存在。多年以后，生成它的人可能已经离开公司，为之创建它的项目可能已经下线，而密钥本身可能还躺在某台被遗忘的服务器、某个泄露的代码仓库或某份旧备份中，依然完全有效，因为系统从未要求它证明自己仍然被需要。
这是一个真实存在却未受到足够重视的安全问题，而不是假设性问题。密钥会通过提交到仓库的配置文件泄露，通过意外记录下请求头的日志泄露，通过比所属项目存活更久的旧备份泄露。永不过期的密钥意味着每一种泄露途径都会无限期地保持危险，没有一个暴露风险自然终结的时间点。而定期轮换或审查的密钥，至少限定了某次泄露可被利用的时长，即使这次泄露本身从未被发现。
我们认为答案并不是强制设置会在没有预警的情况下破坏集成的过期日期，因为那只是用一个问题换来另一个同样令人沮丧的问题：一个因为没人清楚传达的轮换策略而在生产中途失效的密钥。答案在于可见性和控制力，让轮换成为一个经过深思熟虑、知情的选择，而不是要么从不发生、要么作为计划外的意外发生的事情。每个响应中的配额响应头，包括某个密钥的 IP 名额已使用多少个的计数，持续提供信号，表明该密钥的使用模式是否仍然符合其最初签发时的用途，而这恰恰是应当促使人们定期审视“这个密钥是否还需要存在”的那类信息。
业界普遍把密钥视为一次安装、永久有效的凭据，这种习惯源于把初始集成的便利性置于该凭据整个生命周期之上。在第一天生成一个再也不需要碰的密钥，确实更容易。这种便利是前置的，而代价（一个陈旧的、无人监控、从未轮换的密钥作为永久隐患存放在某处）则被后置到了一个第一天没人会去想的未来事故上。
我们认为更健康的默认做法是，不要把密钥当作一次性固定安装的东西，而更多地把它当作与账户保持持续关系的凭据：通过它发出的请求实时可见，可以定期审查，并且在其所属项目真正结束时可以干脆地撤销。这些都不需要对任何人强制设置过期。它需要的是让人足够容易地看清一个密钥实际在做什么，从而让任由旧密钥永远留存不再是阻力最小的选择。