85国机场用47种写法说"起飞"，一个API怎么收拾这烂摊子

全球机场的数据格式乱到什么程度？同一家航空公司的"已起飞"，在西班牙是SAL，在德国是gestartet，在俄罗斯是Отправлен，在爱沙尼亚是Väljunud。没有统一标准，没有行业协议，连大小写都不统一。

开发者Nico Prananta在搭建MyAirports API时，被这个问题堵了三个月。他的目标很简单：让用户查询任何机场的航班，返回7个干净状态——scheduled、boarding、departed、arrived、delayed、cancelled、unknown。但输入端是85个国家、40多种语言的原始网页，每个机场都有自己的"方言"。

这不是翻译问题，是标准化战争。

第一层：硬编码的"字典暴力"

Nico的第一版方案很直接：穷举。他把见过的所有状态字符串塞进一个对象，键是原始文本，值是标准化状态。英文还算老实，"departed"就是"departed"，顶多混进来几个"in flight""airborne"。

西班牙AENA系统最先教他做人。这家管理全国机场的机构用三字母代码：SAL（salida/出发）、AIR（en aire/空中）、FLY、CER（cerrado/关闭）全算"已起飞"。登机叫BOR、EMB、ULL、OPE四个变体。计划中的航班分EST（estimado/预计）和PRG（programado/计划）。

俄语、爱沙尼亚语、芬兰语各自来一套。西里尔字母、拉丁字母带变音符号，编码问题差点让数据库吐出来。

这套精确匹配表覆盖了60-70%的情况。剩下的30%，机场开始玩花样。

第二层：模式匹配抓"动态字符串"

有些机场把实时信息塞进状态字段。"Delayed 00:45"——延迟多久会变。"Gate 23 closing"——关舱门倒计时。"Check-in open"——值机开了，但还没开始登机。

Nico加了第二层：子串正则。/delay/i 抓所有带"delay"的变体，/^cerr/i 匹配西班牙语cerrado的各种变形，/check.?in/i 识别值机状态并映射为"scheduled"而非"boarding"。

这里有个反直觉的细节："Check-in open"被归为scheduled而不是boarding。因为值机开放时旅客还在柜台排队，真正登机是另一个状态。很多前端开发者会搞混这个，直接显示"正在登机"吓跑还没过安检的人。

凤凰城天港机场（Phoenix Sky Harbor）更绝，把实际时间戳嵌进状态字符串。正则在这里变成必需品，精确匹配完全失效。

第三层：未知状态的"兜底哲学"

即使两层过滤后，仍有漏网之鱼。新机场接入、旧机场改版、临时促销代码、系统故障时的异常文本——unknown状态的存在是为了不让整个API崩溃。

Nico的设计选择很产品经理：宁可返回unknown，也不猜错。前端拿到unknown可以降级显示原始文本，或者提示用户刷新。但如果把"Final call"误判为"departed"，用户会错过航班。

整个系统的架构像漏斗：精确匹配→模式匹配→人工复核→unknown兜底。每层都有明确的失败移交机制，没有静默错误。

多语言API的隐藏成本

这个项目暴露了一个行业潜规则：全球化产品的"语言支持"往往止于界面翻译。真正的多语言是数据层的地狱——同义词、缩写习惯、时区表达、文化差异（有些国家"迟到"和"延误"是同一个词）。

Nico在代码注释里埋了个彩蛋：西班牙语CER（cerrado/关闭）在某些机场指"登机口关闭=已起飞"，在另一些机场指"值机柜台关闭"。上下文决定语义，没有全局真理。

这解释了为什么航空数据API的定价模型通常是按机场收费，而非按查询量。每新增一个机场，需要人工审计其状态字符串、建立映射规则、持续监控改版。自动化只能解决70%，剩下的是苦力活。

MyAirports最终把85个国家的混乱压缩成7个枚举值。但Nico的GitHub仓库里，那个300行的EXACT匹配表还在每月增长——上个月新增了波兰机场用"Wylądował"表示到达，上个月底某德国机场把"gestartet"改成了"Gestartet"（首字母大写），精确匹配失效了四小时。

如果你在做跨境数据整合，有没有遇到过类似的"同一概念、百种写法"的坑？最后是用规则引擎硬啃，还是直接上机器学习做语义分类？