永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么我们没有先构建浏览器 SDK
浏览器 SDK 是一个很容易提出的需求，但对于地理编码或 IP 查询 API 实际承担的很多工作来说，它确实是个糟糕的主意。把 IP 地址解析为位置之所以有意义，正是因为它发生在服务器上，在那里可以看到请求的真实来源。把同样的查询放进在访客浏览器中运行的客户端 JavaScript，并不会让集成更方便。您只是把一个带认证的 API 密钥挪到了整条请求路径上唯一一个任何人都能打开开发者工具读取它的地方。
这就是为什么我们没有把浏览器 SDK 放在纯 HTTP 支持和兼容主机之前。无论以 X-API-Key 请求头、Bearer 令牌、HTTP Basic 认证还是查询参数传递，密钥在每个主机上的效果都相同，可以从您服务器端代码已经所在的任何地方调用：后端服务、无服务器函数、批处理任务，任何请求本来就有理由从您掌控的基础设施发出、而不是从您无法掌控的浏览器标签页发出的地方。
IP 地理定位尤其只在服务器端才有意义。这种查询的全部价值来自解析发出请求的真实 IP 地址，而对于大多数有意义的用例（欺诈检查、本地化、您自己掌控而非出售的分析），这需要在该 IP 地址具有权威性的地方进行：您的服务器，直接接收请求的地方，而不是浏览器环境，在那里客户端调用所报告的“IP”要么无关紧要，要么可以轻易伪造。
对用户输入的地址进行地理编码，是否只能在服务器端进行就没那么明确了，确实有理由希望地址自动补全直接在浏览器中的表单里响应迅速，而无需先绕经您自己的后端。我们并不反对这种模式最终出现。我们反对的是把它作为首要和主要的集成路径来构建，排在纯服务器端 HTTP 访问之前，而大多数真实用例（结账流程、运费计算器、欺诈检查）实际需要的正是后者，并且后者无需向公众暴露凭据。
我们所反对的更普遍的模式，是把“提供浏览器 SDK”当成每个 API 都应该勾选的项目，而不管客户端访问那一类数据是否合理。对于服务器端上下文本身就是全部意义的查询来说，浏览器 SDK 大多只是回答了一个营销问题（“这看起来是否现代、方便”），代价则是一个真实的安全问题（“这个凭据最终会存放在哪里”）。我们宁愿先回答安全问题，再让便利性随之而来，而不是反过来。
这一切并不排除我们最终推出一个更轻量、适合浏览器的工具，专门用于客户端使用确实合理的场景，比如一个运行时从不需要您账户真实凭据的表单自动补全。它不应该成为我们要求客户信任的第一样东西，排在已经能安全覆盖大多数真实集成的纯 HTTP 路径之前。