跳到正文

一个湖,三个名字:如何构建能经受事实突变的系统

简要回答

安大略湖如今在美国境内显示为“美国湖”,在加拿大沿用旧名,在其他地方则同时显示两个名字。这件事看似是政治新闻,实则是对所有把名称当作固定事实来存储的系统的一次工程考验。本文是一份实用指南,介绍如何构建能够吸收地名、税率和法规变化而无需每次重写代码的基础设施。

Origami 团队

编辑团队 · · 阅读约 7 分钟

分享到 WhatsApp
喜欢我们发布的内容吗?在 Google 中把 Origami 设为首选来源。Add as a preferred source on Google
一个湖,三个名字:如何构建能经受事实突变的系统

2026年8月27日,美国一项行政命令在联邦地理名称数据库中将安大略湖更名为“美国湖”。三天后,谷歌地图应用了这一变更,苹果地图则在9月2日跟进。加拿大拒绝了这个名字,而两国的边界恰恰从湖中穿过。

结果是,同一个地理实体如今根据观看地点的不同而带有三种标签:在美国的人看到“美国湖”,在加拿大的人看到“安大略湖”,其他所有人则同时看到两个名字。这并非首例;去年墨西哥湾就按同样的逻辑被更名为“美国湾”。

人们很容易把这当作一条政治新闻读过就算了。但实际发生的是一次工程考验:世界上每一个把这个湖的名字存储为固定文本的系统,现在都在向一部分用户显示错误信息。对我们来说重要的问题是:你的系统是否被设计成能够吸收这类变化?

根本错误:存储标签而不是身份

大多数系统存储的是肉眼所见的内容。一个名为“城市”的文本字段里写着“利雅得”,国家字段里写着国家名称,税率是写死在代码里的一个数字。在事实本身发生变化之前,这一切都运转高效;一旦变化发生,你就会发现自己的历史数据再也无法被正确解读。

工程规则很简单:存储一个稳定的标识符,在显示时再生成标签。这个湖是一个实体,它有一个不会改变的标识符,并根据语言、语境和官方来源拥有多个名字。存储标识符,改名就只是更新一张参考表;存储名字,改名就会变成一个完整的数据迁移项目。

沙特企业的日常中究竟有哪些东西会变?

湖是一个遥远的例子。但下面这份清单并不遥远:

  • 税率。沙特增值税在2020年从5%上调至15%,那些把这个数字写进代码的公司度过了艰难的一周。比变化本身更糟的是:旧发票必须保留原来的税率。
  • 电子发票要求。与天课、税务和海关总局(ZATCA)的对接分批分阶段推进,而每一批都可能带来技术规范的变更。
  • 国家名称。Türkiye在2022年成为联合国使用的正式名称,马其顿变成了北马其顿,斯威士兰变成了埃斯瓦蒂尼。任何手工录入到你系统中的国家列表都已经过时了。
  • 国家地址和数据格式。邮政编码、国民身份证号、IBAN和机构编号的格式会更新,而每一个以僵硬的正则表达式编写的校验规则,都会在第一次扩展时失效。
  • 其他市场的税收。如果你在沙特阿拉伯以外销售,变化会来自那些你并不关注其新闻的国家——就像本月应用商店同时在三个国家新增税种那样。

能够吸收变化的基础设施的五条原则

  • 用标识符,而不是标签。把每个实体绑定到一个稳定的标识符上,并把名称保存在单独的表中,这张表允许每个实体按语言和来源拥有多个名称。
  • 为每个可变的值设置生效日期。税率不是一个数字,而是一系列值,每个值都有开始日期和结束日期。仅此一点就能解决按正确税率重新打印旧发票的问题,并避免在第一次审计时出现会计灾难。
  • 把参考数据当作配置,而不是代码。国家、货币、税种和地区的列表应存放在由授权管理员更新的表或配置文件中,而不是存放在代码里的常量中——那样每次修改都需要发布新版本并动用开发团队。
  • 显示层与存储层分离。存储的是一回事,显示的是另一回事。一旦系统把两者分开,向不同用户显示不同名称就只是一项设置,而不是一次重建——这正是谷歌对这个湖所做的事。
  • 唯一的事实来源。如果税率同时写在数据库、发票模板和销售报表中,你就拥有三份副本,而它们迟早会互相矛盾。选定一个位置,让其余部分都从那里读取。

本周对你的系统做一次实用检查

这不需要立项。和你的开发人员坐下来,问五个问题:

  • 如果税率明天变了,我们要修改多少个文件?旧发票还会保持正确吗?
  • 我们的国家和货币列表放在哪里——在一张表里,还是写死在代码里?
  • 我们是把城市名称存为文本,还是存为与参考数据关联的标识符?
  • 如果主管机构给国民身份证号增加一位数字,或者更改邮政编码格式,会发生什么?
  • 系统中有多少处知道税率的值?如果超过一处,那就是你的下一个问题。

这些答案能在半小时内暴露你的薄弱环节,而且如果在需要之前而不是之后处理,大多数问题几天内就能修复。

Origami的观点

我们在这里看到的是一个经常向客户重申的教训:好的系统不是今天能运行的系统,而是无需重写就能适应不断变化的世界的系统。两者之间的差别不在于程序员有多聪明,而在于第一周做出的几个简单设计决定:用标识符代替文本,用生效日期代替固定数字,用参考表代替代码中的列表。

这些决定在开始时只花费几个小时,却能在日后节省数周时间。我们见过一些公司因为一项监管变化而连续数天无法开具发票,而这项变化本来只需更新表中的一行就能吸收;原因总是一样的:一个值被写在了一个从未设计为可变的地方。

结论

一个湖在一个国家被改名,而这个名字在另一个国家被拒绝,于是它如今同时带有三种标签。这不是例外,而是参考数据不断经历的变化的一个缩影。税收、名称、格式和法规会因你无法控制的外部决定而改变。你能控制的是系统的准备程度,而这在设计阶段就已决定,而不是在变化发生的那一刻。

来源

  • 谷歌官方博客——关于在谷歌地图中应用更名以及如何向美国、加拿大和世界其他地区用户显示的声明,2026年8月30日。
  • 路透社、《时代》周刊(TIME)和英国广播公司(BBC)对2026年8月27日行政命令、9月2日苹果地图变更以及加拿大立场的报道。
  • 天课、税务和海关总局(ZATCA),zatca.gov.sa——增值税税率和电子发票各阶段的官方参考来源。
  • 联合国——2022年采用Türkiye作为正式名称,作为国家更名的一个有据可查的例子。
  • #系统设计
  • #参考数据
  • #电子发票
  • #变更管理
  • #基础设施

常见问题

安大略湖的名字发生了什么变化?

2026年8月27日,美国一项行政命令在联邦地理名称数据库中将其改名为“美国湖”。谷歌地图在三天后应用了这一变更,苹果地图在9月2日跟进,而加拿大拒绝了这个名字。

为什么不同国家看到的名字不一样?

因为谷歌根据各国的官方来源显示名称。在美国的用户看到“美国湖”,在加拿大的用户看到“安大略湖”,其他地方的用户则同时看到两个名字。

这和企业的系统有什么关系?

任何把名称存储为固定文本的系统,现在都在向一部分用户显示错误信息。更广泛的教训是:参考数据——税收、国家名称、数据格式——会因外部决定而改变,而你的系统应当在无需重写的情况下吸收这些变化。

最重要的一条原则是什么?

为实体存储一个稳定的标识符,在显示时再生成标签,而不是存储名称本身。这样,改名就只是更新一张参考表,而不是一个数据迁移项目。

税率变化时应该如何处理?

把税率当作一系列值,每个值都有开始日期和结束日期,而不是一个单一的数字。这样旧发票在重新打印或接受审计时仍保持正确的税率。

怎样判断我的系统是否脆弱?

问问你的开发人员:如果税率明天变了,要改多少个文件?国家和货币列表放在哪里?系统中有多少处知道税率的值?多处存放就是脆弱的第一个信号。

有项目想法吗?

我们为您的企业打造定制系统、应用和网站。告诉我们您的想法,我们会给您一个直截了当的答复。

查看我们的服务

简报

新文章和新系列,直接发送到您的邮箱。

在 Google 上关注 Origami

把 Origami 设为首选来源,我们的文章就会优先出现在您的 Google 搜索和热门新闻中。

Add as a preferred source on Google