永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么测试地址数据不应需要先打销售电话
有一种特定的阻碍在地址数据领域格外常见：一个地理编码 API 宣称拥有真实的覆盖范围，营销页面上也有演示，但您无法直接用自己的地址来测试，必须先填写表单，再等待销售代表联系您。设置这道门槛的理由通常是筛选销售线索，或者保护有价值的数据集不被随意抓取。无论理由是什么，结果都是开发者无法回答唯一真正重要的问题，也就是它能否很好地处理我的地址，除非先进行一场与技术问题本身毫无关系的对话。
我们不会把测试挡在销售对话之后。任何地址每天 2,500 次请求，无需密钥，足以把一批您自己有代表性的真实地址通过 API 跑一遍，立即看到返回结果，无需预约任何事情。如果您接下来想要一个密钥，获取它只需要一个电子邮件地址，而不是一通询问您预期用量或使用场景的资格审核电话。
设置测试门槛的冲动，通常源于把评估流量当作需要尽量压缩的成本，而不是把它看作销售流程本身在正常运转。我们认为，对技术产品来说，这恰恰把优先级搞反了。大多数开发者不会因为一段销售话术，或者一个围绕精心挑选的示例地址搭建的演示，就信任一个地理编码 API。他们会在把自己那份杂乱的真实地址列表跑一遍，看到它的实际表现之后才会信任它，包括那些精心策划的演示永远不会包含的棘手情况。
在这一点上，我们也会谨慎地如实说明局限，而不是让便捷的访问暗示超出事实的东西。能够立即测试正向地理编码、逆地理编码和自动补全，无需销售通话，并不意味着这些端点被宣传为已经完全完成、并在每一种地址模式上都经过了准确性验证。它的意思是，您可以直接用自己的数据亲自弄清楚它们实际能做什么，而不是听一个以签下合同结束对话为职责的人来告诉您它们能做什么。
对于真正大规模的合作承诺，销售通话自有其合理的位置，因为就具体需求进行直接沟通对双方都有帮助。但它不应成为横亘在开发者与一个基本问题之间的门槛：这个 API 的地址处理能力是否足以满足他们的使用场景。这个问题值得一个直接的答案，由 API 本身在有人决定一探究竟的第一个下午给出，而不是在下周某个时候的预约通话之后。
我们更愿意用赢得小客户的方式来赢得大客户：让产品直接回答问题。如果地址处理在您自己那份真实而杂乱的列表上经得起考验，这比销售对话能替它说的任何话，都更能支持一项更大的合作承诺。