JSON vs XML：为什么现代 API 都选择 JSON

JSON 和 XML 都是结构化数据格式，但在实际开发中的使用体验差异很大。XML 更明确、更冗长，在一些企业系统和历史接口里仍然常见。JSON 更紧凑、更容易阅读，也已经成为现代 REST API、Webhook、前端应用和日志系统的默认格式。

这里的问题不是 XML 是否已经过时。XML 在 SOAP API、文档格式、需要命名空间的系统、混合文本标记等场景中仍然有价值。更实际的问题是：为什么大多数新 Web API 会选择 JSON？开发者在发送或保存 JSON payload 前，又应该检查什么？

JSON 和 XML 对比

下面是同一份用户数据的 XML 表示：

<user>
  <id>1</id>
  <name>张三</name>
  <email>[email protected]</email>
  <active>true</active>
</user>

对应的 JSON 表示是：

{
  "id": 1,
  "name": "张三",
  "email": "[email protected]",
  "active": true
}

JSON 更短，因为每个字段名只出现一次。XML 中字段名通常既要出现在开始标签里，也要出现在结束标签里。对于很小的 payload，这点差异不明显；但对于大型 API 响应，它会影响可读性、传输体积和调试速度。

JSON 天然对应对象、数组、字符串、数字、布尔值和 null。这些类型和 JavaScript、TypeScript、Go、Python、Java、PHP 等语言里的基础数据结构都很容易互相转换。

因此 JSON 很适合：

JSON 也很适合浏览器调试。开发者可以从 Network 面板复制响应，格式化 payload，截取一小段数据复现问题，而不需要理解额外的标记模型。

XML 有一些 JSON 并不打算替代的能力，比如属性、命名空间、Schema、注释、处理指令，以及文本和结构混合的内容。这些能力在文档型数据和成熟企业系统里仍然有意义。

XML 常见于：

如果数据更像一份文档，XML 可能是合理选择。如果数据更像对象、数组或接口消息，JSON 通常更简单。

一个常见误区是：看起来像 JavaScript 对象的内容，就一定是合法 JSON。实际上标准 JSON 比 JavaScript 对象字面量严格得多。

下面这段是合法 JavaScript，但不是合法 JSON：

{
  name: '张三',
  active: true,
}

标准 JSON 要求字段名和字符串都使用双引号，而且不允许尾随逗号：

{
  "name": "张三",
  "active": true
}

这个区别在 API 接口、数据库 JSON 字段、浏览器 JSON.parse() 中尤其重要。JSON5 和带注释 JSON 可以用于本地配置，但在作为 API 数据发送前，通常应该先转换为标准 JSON。

当接口拒绝 JSON payload 时，原因经常很小：

例如下面这段看起来很清楚，但严格 JSON 解析会失败：

{
  "limit": 20,
  "includeArchived": false,
}

最后一个逗号是非法的。严格解析器可能提示 Unexpected token }，看起来像是右大括号有问题，实际原因通常是前面的逗号。

如果数据要在系统之间交换、写入 JSON 数据库字段、发送到 REST API，或交给标准库解析，优先使用 JSON。

如果外部系统明确要求 XML，或者需要命名空间、Schema、文档型结构，那么继续使用 XML。

如果文件主要由人维护，并且消费方明确支持 JSON5 或 JSONC，可以使用带注释 JSON。但它不应该被当成 API payload 的默认格式。