考古现场：1998 年，一个叫 XML 的"万能语言"横空出世
那是互联网的蛮荒时代。各家公司用各自的私有协议通信，IBM 的系统和微软的系统互不相认，一个企业级系统集成项目往往要耗费数年的定制开发。在这种背景下，W3C 于 1998 年发布了 XML（eXtensible Markup Language）规范——一个声称能让任何软件互相"说话"的标记语言。
XML 的野心是惊人的。它不只是数据格式，它是一整套生态：
- XSD（XML Schema Definition）——定义数据结构的合法性
- XSLT——把 XML 转换成任意格式的样式表语言
- XPath——用类似文件路径的语法查询 XML 节点
- SOAP——基于 XML 的远程调用协议，主导了整个 Web Service 时代
整个 2000 年代初，XML 是软件架构师口中的圣经。企业 ERP 系统用 XML，银行接口用 XML，电商平台用 XML，政府数据交换标准用 XML。如果你的系统不支持 XML，你甚至无法参与政府采购。
一个典型的 XML 报文，用来描述一个用户信息，大概长这样——准备好了吗？
<?xml version="1.0" encoding="UTF-8"?>
<user>
<id>1001</id>
<name>张三</name>
<active>true</active>
</user>112 个字符，传递了 3 个字段。而 JSON 只需要 40 个字符：{"id":1001,"name":"张三","active":true}。
转折点：2006 年，一个叫 Douglas Crockford 的人
JSON 并不是某个大公司发明的。它的"发明者"Douglas Crockford 出名的方式相当草根——他在 2001 年发现 JavaScript 里有个叫 eval() 的函数可以直接解析一种轻量的数据格式，那种格式就是 JavaScript 对象字面量。他注册了 json.org，写了一份简单的规范，然后……就没了。
接下来发生的才是历史。
2004-2005 年，Ajax 技术爆炸式普及。网页开始频繁和后端交换数据，而 XML 的解析在浏览器里奇慢无比（DOM 解析器）。与此同时，JavaScript 可以用一行代码解析 JSON：
// XML 解析（痛苦的）
const parser = new DOMParser();
const doc = parser.parseFromString(xmlString, "text/xml");
const name = doc.getElementsByTagName("name")[0].textContent;
// JSON 解析（一行搞定）
const data = JSON.parse(jsonString);
const name = data.name;前端开发者用脚投票。到 2008 年，主流 Web API 几乎全面转向 JSON。
XML 的反击：它从未真正死去
很多人以为 XML 已经是博物馆文物了，但真相是：XML 在某些战壕里依然是不可撼动的王者。
企业集成仍是 XML 的主场。银行内部的 ISO 20022 金融报文标准是 XML，SWIFT 跨境支付系统的核心协议是 XML，医疗数据交换的 HL7 标准是 XML。这些场景有一个共同特点：数据结构极其复杂、需要严格的 Schema 校验、需要精细的命名空间管理——而这些，正是 XML 生态的强项。
配置文件领域，XML 也没有消失。Maven 的 pom.xml，Android 的 AndroidManifest.xml，Spring 的 applicationContext.xml——大量的 Java 生态工具至今运行在 XML 上。
XML 和 JSON 的核心差异，用一张表就能说清楚：
| 特性 | JSON | XML |
|---|---|---|
| 可读性 | ✅ 简洁 | ⚠️ 冗长 |
| Schema 校验 | JSON Schema（需第三方） | ✅ XSD 原生支持 |
| 注释支持 | ❌ 不支持 | ✅ 支持 |
| 属性/元数据 | ❌ 无 | ✅ attributes 支持 |
| 命名空间 | ❌ 无 | ✅ 支持 |
| 浏览器支持 | ✅ 原生 JSON.parse | ⚠️ DOM 解析器，较慢 |
| 体积 | ✅ 紧凑 | ❌ 冗余标签 |
实战中的互转：何时你需要 JSON ↔ XML 转换？
如果你在现代公司工作，大概率会遇到以下几种经典场景：
- 对接老系统：公司内部有一套 2005 年上线的 ERP，对外只提供 XML 格式的数据接口。你的新 Node.js 服务需要消费它。这时候，JSON → XML 的转换是第一道关卡。
- 银行/政府接口：不少金融机构的 API 文档给你看的是 XSD Schema，返回的也是 XML——你需要在网关层做一次 XML → JSON 的转换，让下游现代服务正常消费。
- Android 开发：解析 AndroidManifest.xml 或布局文件时，理解 XML 属性与 JSON 字段的映射关系，在反射或配置读取时非常实用。
转换时有几个常见的坑值得注意：
- XML 属性 vs 子元素的歧义：
<user id="1001">和<user><id>1001</id></user>在语义上等价，但转换成 JSON 时策略不同，要根据目标系统的期望决定 - 重复节点转数组：XML 允许同名节点重复出现（
<item>A</item><item>B</item>），自动转换时要正确识别并输出 JSON 数组 - CDATA 区块：XML 的 CDATA 用来存放不需要解析的原始文本（如内嵌 HTML），转换时需要特殊处理
2026 年的答案：你该用哪个？
如果你是在搭建一个全新的现代 API，没有任何历史包袱，答案毫无悬念：JSON。轻量、易解析、前端原生支持、生态工具成熟。
如果你在以下场景，XML 仍然是更好的选择：
- 需要复杂 Schema 校验（银行、医疗、政府数据交换）
- 需要 XSLT 转换管道（出版、文档处理行业）
- 对接已有的企业 SOAP 服务
格式从来不是非此即彼的宗教战争。XML 和 JSON 的共存，不是因为有人保守，而是因为不同的问题域需要不同的工具。理解它们各自的设计哲学，才能做出正确的架构决策——而互转工具，正是这两个世界之间的翻译官。