永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
只在发布当天准确的数据带来的问题
数据集在发布当天最容易让人引以为豪。它已经依据当时可用的各种来源进行了检查、清洗和验证，发布公告可以如实宣称出色的覆盖范围和准确度，因为在那个特定时刻，它确实配得上这些说法。问题在于，地理方面几乎没有什么能长期保持不变。行政边界会变动。邮政机构会重新划分或重新发布编码。政府会修改夏令时规则，有时几乎不提前通知。一个在发布当天准确、此后却没有得到积极维护的数据集，已经不再是同一个数据集了，尽管它可能仍以同样的信心被宣传。
IANA 时区数据库是一个说明如何妥善处理这一问题的有用例子：它之所以存在，正是因为时区规则不断变化，并且会随着这些变化的发生而更新，由专门负责追踪此类变动的人来维护。一个利用此类来源并持续从中获取更新的地理编码或位置 API，与一个多年前构建了一次性快照、此后一直在提供这份略加修补的快照的服务商，所做的事情有本质上的不同。
我们认为，持续维护与一次性构建之间的这一区别，在位置数据产品的营销方式中应当得到比通常更多的关注。发布公告可以宣称覆盖广泛的国家，而且这是真的。但它本身无法承诺的是，两年后这份覆盖范围依然属实，因为在此期间，边界变更、邮政重组和时区规则修订都可能已悄然发生，而客户没有任何理由知道需要去核查。
这也是为什么我们把时区、海拔和 IP 数据作为产品中描述最具体的部分，因为在这些领域，底层参考数据（例如 IANA 数据库之于时区的那类来源）从设计上就是持续维护的，而不仅仅依赖服务商内部的更新计划。这也是为什么我们谨慎地避免夸大正向地理编码、逆地理编码和自动补全，不把它们说成已经完全完成并经过验证的准确功能：地址数据尤其在维护质量上存在巨大的地区差异，对其听起来信心十足的说法，理应受到比这类说法通常所引起的更多的审视。
数据集的年龄本身并不是缺陷。一个五年前建立、一直保持更新、维护良好的数据集，比一个在下次改版之前都不会再被重新审视的新数据集更值得信赖。重要的是，服务商是把数据维护视为一项持续的义务，还是视为一个在营销页面上线时就已完成的一次性项目。判断这一点的诚实方式不是看发布公告，而是看服务商在此后的岁月里默默地做了什么。