永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
免费层级真正的用途是什么
设计免费套餐的原因通常只有两种，而且两者截然不同，用上几分钟通常就能看出某家服务商选的是哪一种。一种是为了让开发者真正评估产品：给出足够的用量，让开发者构建真实的集成，用真实数据运行，再决定是否值得付费。另一种是为了提供一点甜头，大到足以引起兴趣，又小到几乎立刻就迫使用户做出升级决定，它的作用与其说是评估工具，不如说是推销话术的第一页。
我们的免费套餐属于第一种。任何地址每天 2,500 次请求，无需密钥；添加密钥后每天再多 2,500 次，按网络计数，同一网络下的无密钥使用和有密钥使用共享额度。这足以构建和测试一个真实的集成，而不是一个象征性的数量，在试用 API 的第一个下午就用完，让您在还没了解任何情况之前就要做出购买决定。
这个区别很重要，因为作为诱饵来设定大小的免费套餐会导致一种特定的、糟糕的决策方式。一个在第一个小时就用完免费请求的开发者，并不是因为产品证明了自身价值才决定升级。他们是在决定是否要继续把时间花在一次被中途打断的评估上，而且往往在这之前，他们甚至还没接触到集成中能揭示数据质量和响应结构是否真正适合其使用场景的部分。这不是真正的评估。这是一次被截断的评估，只不过包装成了免费试用。
为真正的评估而设定大小的免费套餐，会让服务商付出更多成本，直接的原因是其中相当一部分用量永远不会转化为收入。我们认为这笔成本换来的东西值得拥有：一位因为实际测试过产品并且产品确实好用而升级的客户，而不是因为倒计时或请求上限在测试完成前就迫使其做出决定。由真正的评估带来的转化往往更加持久，因为它基于产品本身，而不是基于评估的余地被耗尽。
慷慨的免费套餐还有第二个更不显眼的用途：它能覆盖小型、长期、低用量的使用场景，完全不需要付费账户。个人项目、小型非营利工具、学生作业，这些都不需要为了在合理的每日配额内继续运行而成为付费客户。一个只为到期而存在的免费套餐，并不是为这类使用场景而设计的。我们的免费套餐是有意为之，因为并不是每一种正当的 API 用途都需要成为某人每月预算中的一项开支。