永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
这个行业在 IPv6 普及上仍然犯的错误
IPv6 已经推出了足够长的时间，把它当作次要问题已不再是合理的工程捷径，然而仍有大量与 IP 相关的工具表现得好像 IPv4 才是真正的流量，而 IPv6 只是有空时再处理的例外。这体现在一些细节上：速率限制逻辑围绕 IPv4 式的地址块编写，却没有针对 IPv6 的对等且经过深思熟虑的概念；或者文档在示例中默认使用 IPv4 地址格式，把 IPv6 的处理当作一个隐含的事后补充。
我们有意围绕两种地址族构建了网络级配额跟踪，而不是在以 IPv4 为先的逻辑上打一个 IPv6 补丁。每个网络都有一份共享的免费配额，IPv4 地址按 /24 地址块计算，IPv6 地址按 /48 地址块计算，两者都被视为一等分组，而不是一个作为主要设计、另一个作为迁就。/24 与 /48 之间的区别并不是随意的。它反映了负责分配地址块的区域互联网注册机构实际上如何分配每种地址族，因此在两种情况下，这种分组的实际含义相同，即一个规模合理的网络。
对于位置和 IP 数据 API 来说，这件事做错的后果尤其严重，因为整个网络级和基于 IP 的查询类别，都依赖于对两种地址格式的正确解析、匹配和速率限制。一个悄悄把 IPv6 当作边缘情况处理的 API，更有可能对 IPv6 流量产生不一致的配额行为、错误的网络分组，甚至直接解析失败，而这恰恰发生在 IPv6 采用率持续增长、相当一部分真实请求通过 IPv6 而非 IPv4 到达的时候。
整个行业在这方面投入不足的部分原因是，对很多服务来说，IPv4 流量仍占总量的很大一部分，这使得 IPv6 边缘情况相对于真正做好它们所需的投入而言，显得优先级不高。我们认为这种推理过于低估了趋势线。一个持续增长的流量份额，不适合由把它当作永久少数情况的基础设施来服务，而且系统的核心逻辑以 IPv4 为默认构建得越久，正确修复 IPv6 处理的成本就越高。
这些都不是什么惊人的主张。这只是一个请求：在速率限制、配额跟踪和查询逻辑的实际设计中，像对待 IPv4 一样认真对待 IPv6，而不仅仅是在合规清单上勾一个选项，表明某个 API 在技术上接受 IPv6 地址而不报语法错误。接受一种地址格式，与像对待更常见的格式那样用心地处理它，是两种不同的成就，而这个行业里的很多基础设施实际上只做到了第一种。