JSON vs XML：数据格式对比，哪个更适合你的项目？

选 JSON 还是 XML 这个问题，答案不是"JSON 完胜"。在 SVG、SOAP、企业级系统集成、办公文档这些领域，XML 仍然是默认选择。在 Web API、配置文件、NoSQL 数据库里，JSON 几乎垄断。区别不在于哪个"更好"，而在于哪个生态、工具链和约束更适合你的项目。

这篇对比两者的格式、能力、典型场景，帮你在两者之间做出明确选择。

格式对比

JSON 例子

{
  "user": {
    "id": 42,
    "name": "Alice",
    "email": "alice@example.com",
    "roles": ["admin", "editor"],
    "active": true
  }
}

XML 例子（同样的数据）

<user id="42" active="true">
  <name>Alice</name>
  <email>alice@example.com</email>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

JSON 版本约 110 字节，XML 版本约 200 字节。XML 多出来的开销主要在标签和闭合标签上。

能力对比

XML 的属性（attribute）和元素（element）的区分有时是优点，能区分"元数据"和"数据"，但更多时候让建模纠结。

JSON 的优势

1. 体积小，传输快

同样信息，JSON 通常比 XML 小 30%-60%。在移动 API 和带宽敏感场景，这是硬指标。

2. JavaScript 原生

浏览器和 Node.js 一行 JSON.parse 完事，配一个 JSON Formatter 查看结果更方便。XML 要 DOMParser 然后像操作 DOM 一样遍历，代码量大几倍。

3. 数据结构直观

对象、数组、值，三种基本结构覆盖 99% 数据建模需求。XML 的"属性 vs 子元素"决策没有统一答案。

4. 工具链广泛

所有 NoSQL 数据库（MongoDB、CouchDB）、所有主流 API 格式（REST、GraphQL 内部）、所有前端状态管理（Redux、Zustand）都基于 JSON。

XML 的优势

1. 成熟的 Schema 校验

XSD（XML Schema Definition）能精确约束结构、数据类型、引用关系。JSON Schema 后期才补上，工具链成熟度远不及 XSD。在金融、医疗、政府这些需要严格契约的行业，XSD 是硬性要求。

2. XPath 和 XSLT

XPath 让你用类似 /users/user[@active='true']/email 的表达式精确查询 XML 节点。XSLT 把 XML 转换成其他格式（HTML、PDF、其他 XML）。JSON 没有同等成熟的等价物。

3. 流式解析（SAX）

XML SAX 解析器按事件触发（开始标签、字符数据、结束标签），可以处理 GB 级 XML 文件而不占大量内存。JSON 流式解析器存在但远不如 SAX 普遍。

4. 命名空间

XML 的 xmlns 解决了不同领域词汇冲突的问题。SOAP、XHTML、SVG 都靠命名空间组合不同词表。JSON 没有原生命名空间支持。

"XML 已死"是个误读

XML 在 Web API 领域确实输给 JSON，但在以下领域仍然是标准：

• SVG：矢量图格式，所有现代浏览器原生支持
• SOAP：企业级 Web 服务，银行、保险、政府系统大量使用
• 办公文档：docx、xlsx、pptx 本质都是 OOXML（XML 的 zip 包）
• 配置：Maven、Spring、Android layout、Web.config 都是 XML
• 出版业：DITA、DocBook 用于技术文档和图书排版
• 公文传输：电子发票、电子签章、行业监管报文都基于 XML

如果你的项目跟以上任何一个领域对接，XML 不是选择，是必须。

YAML：第三种选择

user:
  id: 42
  name: Alice
  email: alice@example.com
  roles:
    - admin
    - editor
  active: true

YAML 比 JSON 更紧凑，支持注释。但 YAML 的解析器复杂度远高于 JSON，缩进敏感容易出错。适合人类手写配置（Docker Compose、CI/CD、Kubernetes），不适合 API 数据传输。

决策指南

建模陷阱：属性 vs 元素（以及 @ 前缀）

XML 的「属性 / 子元素」二分在 JSON 里没有对应物，转换器必须约定。ToolVault 的 XML/JSON 转换器 默认把属性写成带 @ 前缀的键（@id、@active），混合文本在开启选项时落在 #text / #cdata。这样能干净往返；XML→JSON 时丢掉属性，等于静默丢失 SOAP / SVG 里的一等公民字段。

两边你都能改时，定一条规则并写进 schema 旁注：标识与开关用属性，嵌套结构用元素——或者 JSON 消费者讨厌 @ 时全部用元素。避免后人把 @id「整理」成 id 再搞坏反向转换。

数组与单一 XML 根

顶层 JSON 数组、多键对象在 JSON 合法，在 XML 别扭（XML 要单一根）。生硬的 builder 可能吐出 <0>…</0> 下标标签或校验器不认的多根。转换器默认把数组和标量包进 <root>，并提供可选的 JSON→XML 根元素名，以便你有意输出 <items>…</items> 或 <doc>…</doc>。强制数组标签（role、item…）让「今天一个兄弟、明天多个」的形状对 schema 消费方保持稳定。

超过 Number.MAX_SAFE_INTEGER 的大整数在 JSON→XML 路径上按数字文本保留，避免账号 ID / 雪花被四舍五入——可先用 JSON 格式化工具 检查 JSON 侧。

XML 进流水线时的安全注意

不可信 XML 有 XXE 与实体膨胀风险。优先关掉外部实体的解析器（浏览器内转换器即如此）。不要为了让厂商样例能解析就在服务端打开「解析实体」。JSON 文档解析攻击面更小，这也是公开 HTTP API 普遍选 JSON、内部系统仍可留在 XML 的原因之一。

在本地完成格式转换

无论你在解析 API 响应、把 XML 转 JSON，还是把 JSON 转 YAML 写配置，这些操作都涉及业务数据，最好别贴到陌生网站。

JSON 格式化工具 处理 API 响应和配置文件，XML/JSON 转换器 在两种格式之间互转，JSON/YAML 转换器 和 YAML/JSON 转换器 帮你处理配置文件。所有解析和转换都在浏览器本地完成，数据不离开你的设备。

选 JSON 还是 XML，看的是生态、工具链、约束要求，而不是哪个「更先进」。

排查注记

开篇就拒绝「JSON 完胜」的叙事，把选型框定为生态、工具链与约束的匹配——「XML 已死是个误读」一节列出 SVG、SOAP、OOXML、公文传输这些 XML 不是选择而是必须的领域。建模陷阱一节讲 @ 前缀约定，理由很具体：XML 转 JSON 时丢掉属性，等于静默丢失 SOAP/SVG 里的一等公民字段，所以建议把「标识用属性、嵌套用元素」写进 schema 旁注，防止后人把 @id 整理成 id 再搞坏反向转换。结语与开头呼应同一句话：看生态工具链约束，不看哪个「更先进」。