气象数据前端实战 · 第五篇（格式迁移篇）。前情：篇 1 十行代码跑通地图、篇 2 三种报文一次讲明白、篇 3 跟着一条 SPECI 走完观测线、篇 4 把一份 TAF 展开成时间线。这一篇的讲法不太一样：不拆解析、不拆展开，讲一件正在整个行业发生的事：你在这四篇里读过的每一个字符，都是一种叫 TAC 的电码——而全球航空气象正在把它换成 XML。
先请出主角——上海浦东机场的一份实况报文，一个雾天早晨的典型场景。语料是 WMO iwxxm-translation 仓的 TAC/IWXXM 官方等价样例对（metweave 是我写的一个开源气象工具库，语料随仓发布在 corpus/iwxxm/metar-pairs/）：
METAR ZSPD 290000Z 13003MPS 0800 R17L/P2000 R16R/0600N R17R/1600U R16L/0900U FG BKN002 13/13 Q1018 BECMG TL0130 3000 BR SCT004 BKN020
这行以 METAR 开头的电码，是机场定时发的实况天气报文。翻译过来大概是：浦东 0 点（世界时）观测，风向 130 度 3 米每秒，能见度 800 米，四条跑道视程，雾，云底 60 米，气温露点都是 13 度，趋势至 01:30（观测后一个半小时内）转好到 3000 米轻雾。
同一份观测，行业的另一种写法长这样（同一份报文的官方 XML 版，节选）：
<iwxxm:METAR xmlns:iwxxm="http://icao.int/iwxxm/2023-1" …>
<iwxxm:issueTime><gml:TimeInstant …>
<gml:timePosition>2023-05-29T00:00:00Z</gml:timePosition>
</gml:TimeInstant></iwxxm:issueTime>
<iwxxm:observation>
<iwxxm:MeteorologicalAerodromeObservation cloudAndVisibilityOK="false" …>
<iwxxm:surfaceWind><iwxxm:AerodromeSurfaceWind variableWindDirection="false">
<iwxxm:meanWindDirection uom="deg">130</iwxxm:meanWindDirection>
<iwxxm:meanWindSpeed uom="m/s">3</iwxxm:meanWindSpeed>
</iwxxm:AerodromeSurfaceWind></iwxxm:surfaceWind>
<iwxxm:visibility><iwxxm:AerodromeHorizontalVisibility>
<iwxxm:prevailingVisibility uom="m">800</iwxxm:prevailingVisibility>
</iwxxm:AerodromeHorizontalVisibility></iwxxm:visibility>
…
一行电码，变成了一大篇带标签的结构化文本，长得像网页源代码。这种格式叫 IWXXM（ICAO Meteorological Information Exchange Model，国际民航组织气象信息交换模型）——航空气象报文的 XML 形态。它不是某个公司的产品提案，而是国际民航组织（ICAO）已经写进标准、各国正按时间表迁移的既定路线。
这意味着什么？对飞行运行，意味着数据交换的底座在换代；对写代码的你，意味着：未来几年，你解析的输入、你对接的数据源、你依赖的数据管道，都会多出这一种格式。这一篇拆三件事：XML 化到底解决什么、全球和中国各走到哪一步了、以及「换了格式」之后那些转不过去的信息。不写代码的读者照旧有你的位置：除第五、七节外都不需要代码背景，代码段照旧可以跳过，不亏。
一、TAC 的黄金时代与天花板
先给老主角一个交代。TAC（Traditional Alphanumeric Code，传统字母电码）的血统可以追溯到电传打字机时代：METAR 的骨架在 1968 年前后定型——比 ARPANET 切换 TCP/IP（1983 年）还早十五年。它为「字符按位传输、人眼值班判读」的世界设计，优点至今成立——极省字符（按字符计费的电报时代，0800 四个字符，比把「能见度 800 米」写成几个英文单词便宜得多）、全大写无歧义字符集、抗线路噪声。
但它的一切短板也都来自这个出身：
-
无自描述。
0800是 800 米能见度、时间 08:00 还是跑道号？得靠「第几组」的位置约定——错位一位，后面全部读歪，而报文本身不携带任何纠错线索； -
校验靠下游。电码写错了（能见度是四位编码，写成五位
99009——位数先就不对），交换链路上没人拦得住，一路传到解析器才报错——报错的位置离犯错的位置越远，排查越贵； -
扩展靠补丁。想加一个新要素？只能在 RMK 备注段里塞国家惯例的自由文本——美国把海平面气压塞在这里，中国把修订标识塞在这里——机器没法可靠消费；
-
时间是相对的。
290000Z没有年没有月——篇 4 拆过月锚问题，那是解析器的事；对交换链路，这意味着「这份报文哪天过期」本身就不是报文内可回答的问题。
半个多世纪里这些都能忍，因为消费方是人类管制员和预报员，机器只是抄写员。但当天气数据要喂给自动化系统——飞行计划引擎、告警系统、AI 模型——「位置约定 + 下游校验 + 自由文本」这套契约就开始漏水了。
二、XML 化解决什么
IWXXM 对 TAC 的替换不是「换个皮」，是把上面四个短板逐条对掉：
一，schema 校验前移。 IWXXM 报文自带 XML Schema（XSD）加 Schematron（用断言规则写业务约束的另一层校验）双层关卡：标签嵌套错、类型错、必填缺失，在交换网关就能拦下——像快递入仓先扫码验货、再开箱抽检，两道关都设在仓库门口，而不是等收货人发现少了东西。「报文合不合法」从「每家解析器自己猜」变成「对着官方 schema 一锤定音」。（一条边界先说清：这层校验是格式与官方工具链带给交换链路的好处；metweave 这类解析库做的是宽容解析，不是校验器——两件事各归各。）
二，字段自带语义。 回看篇首的对照：0800 变成了 <prevailingVisibility uom="m">800</prevailingVisibility>——是什么、单位是什么、值是多少，三个信息全在标签里。风向 130 度写成 meanWindDirection uom="deg"，3 米每秒写成 meanWindSpeed uom="m/s"。天气现象不再靠背电码表：「雾」从一个要背的缩写 FG，变成一个带编号的正式条目链接（指向 WMO 4678 电码表的 URI）——机器顺着链接就能查到它是什么，不依赖于读者脑子里那张对照表。
三，时间与地点补全。 TAC 里不存在的年月，XML 里是绝对时刻 2023-05-29T00:00:00Z——挂在 gml（地理标记语言，XML 世界里描述时间与位置的通用件，航空气象直接借用）的时间元素上；TAC 里只有一个四字码的站点，XML 里是一整个机场快照——名称、ICAO/IATA 双码、经纬度、标高（如 4 米）、垂直基准面，这个结构借自 AIXM（Airspace Information eXchange Model，空域信息交换模型，机场与跑道在它那里有现成的建模，和 IWXXM 同属一套标准族）。代价是转换器必须外接站点目录才能从 TAC 生成这些内容——这个「库外依赖」第七节还会再碰到。
四，语义显式到了「缺测」这一层。 TAC 里「没有这组」可能是「没观测」「设备坏了」「被扣发」三种完全不同的情况，全靠读者猜；IWXXM 用 nilReason 把缺测的原因写成属性——不是一张实体的表，而是一套标准化的「缺席措辞」，每种原因各领各的词。metweave 从第一版起就把「为什么缺」记下来（省略/缺测/有值，篇 3 讲过的三态），跟新格式的思路撞了个正着——这也是解析 IWXXM 几乎零阻力的原因。
一句话：TAC 是给人读的密码本，IWXXM 是给机器读的数据结构。
三、全球迁移进行时
「正在换」不是修辞，是排了时间表的动作：
-
2020 年 11 月 5 日：ICAO 附件 3 第 78 次修订纳入 METAR/SPECI/TAF，第 79 次修订纳入 SIGMET（均于同日适用）；同批修订保留 TAC，从此进入双轨制；
-
2025 年 11 月 27 日：首个 PANS-MET 适用（附件 3 同步第 82 次修订），数字交换的规则继续收拢；
-
亚太区域：过渡收口排在 2028 年 11 月 23 日（亚太 MET 会议文件里的阶段里程碑）。「TAC 至少保留到 2028」的说法来自 ICAO 亚太 MET 会议的 Phase V 里程碑，说的就是这个亚太口径；公开渠道未查到全球统一的 TAC 停用日官方原文。
参照系给两个：欧洲区 2020 年起就在并行交换，美国转换中心的 IWXXM 产出已成规模——亚太大多数成员国的进度落在这两者之后。
进度怎么样？ICAO 2026 年 4 月亚太 MET 会议文件里有一句表述：「IWXXM 格式数据的可得性与分发仍存在持续缺口」。翻译一下：标准立了六年，区域里仍有国家没把 IWXXM 流真正跑起来。这不是一个已完成的迁移，是一个进行到中段的迁移——这也是这一篇值得写的原因。
四、中国的应用情况：制度已备，通道已画
这是本篇最想写清楚的一节，也是中文互联网上目前没有系统写过的部分。
先说清楚：以下全部来自公开渠道——民航局官网文件、ICAO 会议公开文件、可复现的公开接口实测；「公开渠道未见」不等于不存在——下文所有「未见」都按这个意思理解。
制度面，今年刚落了一子。 2026 年 9 月 8 日，民航局印发民航规〔2026〕19 号《民用航空飞行气象情报发布与交换规定》（AP-117-TM-2026-01，替代 2009 年版《民用航空飞行气象情报发布与交换办法》（AP-117-TM-01R2）；官网 PDF 原文），自 2026 年 11 月 15 日起施行。
这份文件做了两件要紧事。其一，第六条：机场天气报告、机场预报、SIGMET 等各类飞行气象情报「应当符合 TAC 或 IWXXM」——IWXXM 第一次在中国行业规章层面与 TAC 并列为合规格式。其二，附件 1 的报头格式表给全部报文类型配齐了 IWXXM 报头编号，与 TAC 报头双列并排——「报头」是电报时代全球公报交换的地址标签（谁发的、是什么类型），相当于每份报文的邮寄编号；格式换了，邮寄体系也得配套换新（比如 TAF 的报头由 FT 换成 LT，METAR 由 SA 换成 LA，全表见本篇「中国报头双列表」配图）。
这份文件该这么读：制度已铺路、通道已画好；但文件本身没有规定国际交换的 IWXXM 切换时间表，境外交换流程仍按 TAC 公报体系描述。
业务面，公开渠道未见实际发布。 截至近期公开渠道查询，公开渠道查不到中国官方对外发布的中国大陆机场 IWXXM 报文、试点通报或实施时间表（国际会议上官方参与有公开痕迹，但对外发布报文这件事本身未见）。一个可复现的旁证：WMO 信息系统 WIS2 的加拿大镜像全球发现目录（GDC，wis2-gdc.weather.gc.ca）里检索「IWXXM」，本次实测命中只有三条、都是加拿大气象局发布的；中国气象局节点（cn-cma）下的五个公开数据集里均无航空气象 IWXXM。今天你想拿到中国大陆站的 IWXXM，公开途径只有一条——下一节讲。
生态面，「政策热、业务静」。 2026 年公开渠道能看到的范围内：中文期刊未发现 IWXXM 新发表论文（唯一一篇系统文献是 2025 年《气象科技进展》上民航局空管局航空气象中心团队的 IWXXM 浅析一文（原文）——作者单位与 19 号文落地单位同源，从论文到规章，推进的痕迹在公开渠道连得起）；GitHub 全站三十多个 IWXXM 相关仓库，2026 年活跃维护者中未见中国大陆开发者；行业媒体暂未见宣贯报道——施行在即而宣传未响，本身就是个值得盯的信号。JavaScript/TypeScript 生态里 IWXXM 解析库为零——metweave 0.3.0 把双向转换随包发出，补的就是这个空位。
区域对照，各走各的路。 中国香港天文台是华语圈的 IWXXM 推手：2022 年平台功能上线，2026 年一年内多次向 ICAO 提交 IWXXM 状态文件，其中一份专门讨论 TAC 退场与 SWIM（全球航空信息共享的骨干网）建设的挂钩；中国台湾年内上线了自建的新航空气象系统，官方施政报告载明自研过 IWXXM 转换系统。注意台港澳民航体系各按 ICAO 标准运转，与中国大陆民航局体系不是一套，读的时候别混。
五、代转的现实：今天就能拿到中国站的 IWXXM
美国 NOAA 航空气象中心（AWC）运营着覆盖面最广的公开报文 API 之一，其中 METAR 和 TAF 都支持 IWXXM 格式输出——包括中国大陆的观测站。免鉴权，浏览器地址栏就能验：
https://aviationweather.gov/api/data/metar?ids=ZBAA&format=iwxxm
https://aviationweather.gov/api/data/taf?ids=ZSPD&format=iwxxm
拿一份真实的（AWC 2026-10-05 实时流，ZSPD）看关键字段——TAC 原文只有一行：METAR ZSPD 050600Z 34008MPS CAVOK 24/12 Q1018 NOSIG，翻译成 XML 后，根元素头上挂着这些属性：
<iwxxm:METAR … translationCentreDesignator="KKCI"
translationCentreName="NWS/AWC"
translatedBulletinReceptionTime="2026-10-05 06:05:23"
permissibleUsage="NON-OPERATIONAL">
四个属性，每一都在说实话：转换中心是 KKCI（美国），转换时间 10 月 5 日 06:05，用途标记 NON-OPERATIONAL（非运行用途）。
所以有一句话必须钉死：代转 ≠ 官方发布。AWC 流里的中国站 IWXXM 由美国转换中心代转，法律地位明确标注——它能证明「格式链路通了」，不能证明「中国已在发布 IWXXM」。第四节「公开渠道未见官方对外发布」与本节「你今天就能拿到」不矛盾——前者说的是发布主体，后者说的是获取渠道。
六、XML 不是银弹：转换有损面
如果说前五节是 IWXXM 的赞歌，这一节是它的体检报告。同一份天气信息在两种格式之间迁移，有些内容注定到不了对岸——而且最有意思的丢法，恰恰藏在官方代转件里。
回看第五节那条 ZSPD：TAC 原文写的是 CAVOK——能见度 10 公里以上、无低云、无重要天气，一个词三重承诺。XML 里变成了什么？
<iwxxm:MeteorologicalAerodromeObservation cloudAndVisibilityOK="false" …>
…
<iwxxm:prevailingVisibility uom="m">9994</iwxxm:prevailingVisibility>
两处走样：cloudAndVisibilityOK 竟是 false（CAVOK 的显式语义没有被承转）；能见度不是 9999（TAC 的「≥10 公里」上限电码）而是 9994 米——从输出形态看，是管线把单位折成英里再折回米、双向取整的结构性走样（内部具体换算层数未见 AWC 官方说明，这半句属推断，走样本身是确定复现的）。AWC 对 41 个站的实测复现了这一换算走样。同样地，风速 8 m/s 在 XML 里变成了 uom="[kn_i]">16——15.55 节四舍五入的正常结果，不构成走样。[kn_i] 是国际单位码（UCUM）里「节（国际）」的标准写法，连单位都走标准词表，这正是 XML 化想要的精确；只是转换中心顺手把 8 米每秒折成了 16 节（节是航空航海通用的速度单位，1 节 ≈ 0.514 米每秒）。
这是双通道结构性走样，不是 bug：转换链路以英里/节为内部单位，两个方向各自取整，TAC→IWXXM 就不可能逐字节还原。metweave 解析这份报文时也会当场出声——一条 info 级告警：「CAVOK 的显式语义在代转链路里丢失，按组省略收下」还有的组干脆不输出：RVR（跑道视程，篇首出现过的那组）、趋势预报组、NIL 报、风切变都不在 AWC 代转件里；最隐蔽的是变量风范围——TAC 里 350V090（风向在 350°顺时针经 0° 摆到 090°）转成 XML 后整个消失，只剩平均风向，连告警都没有：丢失发生在转换中心那头，只吃 XML 的解析器原理上看不见它，而侧风计算、跑道选配要用这个量。metweave 0.3.0 的文档已把这条写成校验规则。给拿这些数据做下游计算的人三条准则：能用 CAVOK 位就别拿能见度数值凑；≥9999 这类阈值判断会把 9994 判假，余量要留出来；风速比较前先把单位归一。
反过来的好消息也有：官方等价对（篇首那份雾天 METAR）里，RVR 的趋势位 U/N/D（上升/无变化/下降）被完整编码为 pastTendency="UPWARD/NO_CHANGE/…"，逐组保真——格式本身建模是全的，丢不丢取决于转换器。「XML 格式 ≠ 完整语义」，两件事要分开评。
另外两处经典的语义陷阱，解析器必须显式处理（metweave 的解法见 IR 设计，篇 3 讲过）：
-
9999 ≠ CAVOK。9999 只承诺「能见度 ≥10 公里」，不承诺无低云无天气；CAVOK 是三重承诺。混用的系统生成的 XML 里两者长得一样——所以 metweave IR 把
cavok布尔与能见度数值分作两个字段，两种语义各回各家； -
NIL 与缺测的选词即语义。整报 NIL（站点无观测）、RVRNO（设备在但不可用）、
//（自动站无该传感器）在 IWXXM 里对应不同 nilReason 词汇——两套「缺测哲学」的对齐表必须逐位建，选错词就是丢信息。
七、动手：双编码一条龙
说了这么多，写代码的部分反而简单——因为 metweave 0.3.0 把 IWXXM 当成 TAC 的对等公民：同一份 IR（篇 3 拆过的 MetarReport）、同一张卡片、同一层地图。解析一个 IWXXM 报文：
import { parseIwxxm, renderCard } from "metweave";
// xml 即第五节 AWC API 的返回体（目标 2023-1，2025-2 容错解析）
const report = parseIwxxm(xml);
if (report.kind === "metar") { // kind 位判别：目前 parseIwxxm 仅收 METAR/SPECI（TAF 有单独入口）
const card = renderCard(report, { locale: "zh", raw: true });
document.querySelector("#card")?.append(card); // renderCard 返回 DOM 元素，挂载由你做主
}
renderCard 不藏「mount」之类的挂载选项——它返回一个可直接进页面的 DOM 元素，往哪儿放是宿主的事；raw: true 附带原文对照视图，而 0.3.0 的一个彩蛋正好用在这里：altRaws 选项能把两种编码摆进同一张卡片的 tab 组（「TAC / IWXXM」一键切换），tab 界面是现成的；源 TAC 藏在 AWC 代转件的 XML 注释里，正则抽出来、parse 一下、组装成选项——三行胶水还是要自己写，开源仓的 examples 里有现成实现可抄。
parseIwxxm 内部先做版本探测——从 xmlns URI 的末尾段里读出这是 2023-1 还是 2025-2（实测两种都支持，AWC 当前实时流就是 2025-2）；碰到未知版本不炸，出一条 info 级告警继续解析：「IWXXM 版本 XXXX-X 非支持版本（2023-1/2025-2）——按同名空间元素尽力解析」。多版本并存是 IWXXM 世界的常态：标准一年演进一两版，各国启用节奏又不一，第三节的全球时间表只是进度的一个切面——解析器把「尽力而为 + 不静默出声」当成契约，和篇 3 讲的 TAC 侧纪律一脉相承。告警元素是 { code, severity, message } 三件套，消费时按 severity 分级——别按 code 字面吓自己，「invalid-format」也可能是 info 级的宽解提示。生产管道里更稳的入口是 tryParseIwxxm：同样的解析，不抛错、返回结果对象，坏报文不会打断你的批处理。
反向也一样，serializeIwxxm 把 IR 生成回 IWXXM XML——但这里有一个必须由你亲手交出的东西：日历上下文。
serializeIwxxm(report, {
calendar: { year: 2023, month: 5 }, // 必须
version: "2023-1", // 有缺省，显式传更清晰
permissibleUsage: "OPERATIONAL", // 有缺省，显式传更清晰
});
不交会直接抛错，错误文案把原因说得明明白白：「IR 时组只有 ddHHMM 无年月位，绝对时刻（gml:timePosition）的年月必须由调用方注入，不猜不默认」——篇 4 讲月锚时说的「TAC 报文里没有年月」，在 IWXXM 侧反转为一个显式的 API 参数：电码丢掉的信息，换成 XML 时必须有人补回来，解析器拒绝替你编。§二预告的「库外依赖」在这里也是同一件事：序列化时机场快照（名称、坐标、标高）同样要靠调用方注入的站点目录——TAC 里没有的，XML 侧不会凭空长出来。两个缺省值也交代一下：序列化出口缺省是 2023-1（AWC 实时流入的是 2025-2，进出两侧版本不一致是常态不是事故）；permissibleUsage 缺省是 OPERATIONAL——自己生成的报文不会自带「非运行」标记，这条边界得调用方自己记得。
因为两种格式共享同一 IR，测试可以双通道对跑：官方等价对（TAC 一份 + XML 一份，同一观测）分别走 parse 和 parseIwxxm，断言两份 IR 深度相等。有四位要除外——raw 与 span 是原文保真位（TAC 侧存电码、XML 侧存标签，本就不同源），warnings 是告警位（两侧告警体系不同源，比不出意义），cavokSpan 同理。可抄的断言就这么几行：
// 教学版片段：34 对中 30 对会通过；BGTL/CYEK/VTUO/CWFD 四对会红，原因见下
const clean = (r: object) =>
JSON.stringify(r, (key, value) =>
["raw", "span", "cavokSpan", "warnings"].includes(key) ? undefined : value);
if (clean(parse(tac)) !== clean(parseIwxxm(xml))) {
throw new Error("等价对两侧 IR 不等");
}
这 34 对官方等价对全部来自 WMO iwxxm-translation 仓，随开源仓发布在 corpus/iwxxm/（npm 包里只有编译产物不带语料）。实测 30 对通过这道双通道断言；4 对（BGTL/CYEK/VTUO/CWFD）是固有分歧样本——前三对 TAC 侧保美制单位（英寸汞柱、英里），官方译文折成了百帕/米，同值不同单位；CWFD 的官方译文补了 TAC 原文没有的 RVR 缺测标注。分歧不在格式建模，在转换器的单位口径，仓内测试对这四对改走单通道快照并逐站写明理由（packages/parser/src/iwxxm-corpus.test.ts，权威口径以它为准）——拿语料当自己项目的回归底座时，记得把这条排除口径一起带走。
本节代码可照抄可跑：版本探测告警、日历注入报错均对 npm 0.3.0 逐字复现，等价对断言 30 对全等、4 对分歧有案。上一节那张「同一张卡、tab 一键切换 TAC/IWXXM」的配图，实拍自开源仓的标准演示页（首页地图）：AWC 实时流入卡，原文区自带双编码 tab——同卡 tab 是第一种形态。演示页 examples/iwxxm.html 还有另一种形态：双卡逐字段对照，都随仓可玩。
八、现在该做什么
给三类读者的行动清单：
写代码的：把 AWC 的 format=iwxxm 拿来练手（第五节两条 URL），用 parseIwxxm 跑一遍，感受一下 schema 化输入和电码输入在你手上的差异；关注 WMO 官方仓 iwxxm/iwxxm-translation 的 schema 与等价对更新——版本年更，多版本解析是刚需不是洁癖。边界也一并说清：这条通道练手、看板、原型随便用，但报文上印着 NON-OPERATIONAL、接口也没有任何服务承诺，运行决策不能拿它当数据源——免费数据源的这条边界，篇 1 就立过，这里再立一次；也别把产品单押在这一个通道上——免费免鉴权的接口断供不需要理由，上游完成换轨后自建转换才是长期解。两个实践细节：API 缺省每站只回最新一份，回填历史要加 &hours= 参数；拉回来的报文按「站号+观测时刻」去重、用报文自带的接收时间对账。
民航气象从业者：民航规〔2026〕19 号 11 月 15 日施行在即，重点看附件 1 的报头双列表与第六条的双格式合规要求；同团队 2025 年那篇《气象科技进展》论文是目前唯一系统的中文文献，值得精读。
所有人：盯一个观察点，不需要任何专业工具——以后刷到「中国机场开始发新格式报文」的新闻，就是这件事破冰了。19 号文 11 月 15 日施行后，公开渠道会不会出现中国大陆官方的 IWXXM 样例报文或宣贯材料，到时回头再看这篇，第四节就该有续集了。
九、下一篇：站点是点，网格是面
报文的世界（TAC 与 IWXXM）到这里讲完了：系列前五篇，全部在讲「点」——一个机场、一条报文、一张卡片。但天气还有另一半：格点。温度场、风场、降水，铺在面上而不是落在点上；可视化从「站点圆点着色」跨到「网格填色」，色标怎么定、分级怎么切、等值线怎么画才专业，是另一套工程审美。metweave 的 @metweave/grid 包已经随 0.3.0 发出（吃 GRIB2——气象格点数据的标准格式——吐色斑图），下一篇拆讲它。
站点是点，网格是面。下一篇见。
-
仓库：github.com/yaojaro/met…（Gitee 同步镜像 gitee.com/yaojaro/met…）
-
npm：
metweave（伞包，MIT 协议）+@metweave/parser/@metweave/render/@metweave/leaflet/@metweave/grid（按需单装） -
本篇例文均为官方公开语料：TAC/IWXXM 等价对取自 WMO iwxxm-translation 仓（随 metweave 仓
corpus/iwxxm/发布），AWC 代转件实测于 aviationweather.gov 公开 API；法规引用为民航局官网公开 PDF 原文；亚太会议文件表述转引自 ICAO APAC 公开文件库（MET SG/30–WP/06 等）；代码实测于 0.3.0
YaoJaro · 独立开发者，正在造 metweave——把公开气象数据编织成可嵌入产品的图。
系列会一直写下去，欢迎在掘金关注 @MetWeave。
