JSON 和 XML 解决的是有重叠但并不相同的问题。JSON 更紧凑地表示值、对象和数组；XML 表示带有顺序、元素、属性、命名空间、文本、注释和处理指令的文档树。“哪个更好”不是完整问题，更有用的提问是：哪种信息模型、协议生态、解析模式、校验语言和运维约束符合当前系统。

核心要点

  • 当契约主要是有类型的数据，且客户端已有 JSON 生态时，JSON 通常更自然。
  • 当命名空间、混合文本与标记、文档顺序、属性或成熟 XML 标准是核心要求时，XML 可能更合适。
  • 两者都没有普遍的性能或体积优势，应比较等价解析器、校验、压缩、载荷和工作负载。
  • JSON Schema 与 XSD 是不同的契约语言，二者都不会自动提供认证、授权或业务不变量。
  • XML 安全高度依赖解析器配置，尤其是外部实体和资源解析；JSON 安全也取决于消费语言和上下文，不是语法自动保证的。
  • 格式转换是可能丢失信息的模型变换，可能损失顺序、属性、命名空间、混合内容、类型、注释或重复名称。迁移前必须定义映射。

快速比较

关注点 JSON XML
核心模型 对象、数组、标量 有序元素树、属性、文本、命名空间
原生类型 字符串、数字、布尔、null 字符数据，类型可由 XSD 或应用规则约束
命名空间 数据模型没有命名空间机制 支持命名空间 URI 和前缀
混合内容 表达不自然 原生支持文档内容
注释/处理指令 标准 JSON 不支持 XML 语法支持
校验 JSON Schema 词汇 DTD、XSD、Schematron 和应用规则
查询/转换 JSONPath/jq 和语言库 XPath、XQuery、XSLT 和语言库
常见协议 JSON API、JSON 事件 SOAP、RSS/Atom、行业和文档标准
主要迁移风险 导出时丢失文档/命名空间元数据 扁平化时臆造数组、属性或类型

这张表只是起点，不是独立于契约的基准或推荐。

数据模型与文档模型

JSON 表示值树。对象成员顺序通常不属于语义，重复成员名存在实现差异，数组是有序序列。JSON 没有标准注释、命名空间或混合内容模型。

XML 表示有序树。一个文档可以区分元素内容、属性、文本节点、注释、处理指令、命名空间 URI 和实体引用。在文档型词汇中，属性与元素并不自动等价，空白也可能有意义。

例如，下面 XML 携带命名空间和混合内容：

xml 
<p xmlns="urn:example:doc">
  Read <em>carefully</em> before signing.
</p>

将它映射为 JSON 时，必须决定如何表示命名空间、文本顺序和 em 子元素，不存在唯一正确的对象结构。

类型与校验

JSON Schema 可以断言 JSON 类型、必填属性、数组、格式和组合。XSD 可以约束 XML 元素、属性、命名空间、顺序和数据类型。Schematron 可以表达规则型断言。这些系统语义不同，不能直接互换翻译。

应在契约中固定精确方言和验证器版本。JSON Schema 的 format 可能是注解或断言；XSD 校验也不会授权用户访问对象。Schema 校验之后仍需执行业务规则、认证、授权和资源限制。

API 与生态契约

当载荷是数据对象，且客户端已有 JSON 解析器和生成模型时，JSON 很适合 API。若行业契约、SOAP/WSDL 工具链、命名空间文档或签名 XML 流程已经是权威来源，XML 可能是更低风险的选择。

媒体类型也是契约的一部分：

  • application/json 表示 JSON 语法和处理预期；
  • application/xml 或更具体的 XML 类型表示 XML；
  • 内容协商、字符集、规范化、签名和错误格式必须单独记录。

不要只因框架中某个解析器方便就选择格式。已有客户端、标准、运维工具和长期兼容性通常比局部语法偏好更重要。

性能：测量完整路径

把 JSON.parse 和浏览器 DOMParser 对比，不能证明 JSON 普遍更快：前者是原生值解析，后者产生文档树。XML 也有 SAX、StAX 等流式解析器，而 JSON 既可以一次性加载成内存对象，也可以增量处理。

应使用生产相同或等价的路径测量：

  1. 实际解析模式（DOM、流式、拉取或事件式）；
  2. 包含 Schema 校验和转换；
  3. 压缩与未压缩传输；
  4. 峰值内存、CPU、延迟、吞吐和失败行为；
  5. 真实载荷大小、嵌套、文本、命名空间、数组和客户端硬件。

不要重复“JSON 通常小 30–50%”等固定结论，除非公布样本集、序列化策略、压缩方式和测量日期。空白、重复标签、字段名、压缩和文档特性都可能改变结果。

安全边界

XML

除非契约确实要求，否则配置解析器关闭外部通用实体、外部参数实体、DTD 抓取、网络访问和无界实体展开。限制字节、深度、节点、属性、文本长度和处理时间。XXE 与实体展开风险通常来自解析器配置失败，而不是所有 XML 文档天生不安全。

JSON

JSON 语法本身不会造成原型污染或 XSS。这些风险发生在解析数据被合并进 JavaScript 原型、插入 HTML/JavaScript、用作 URL 或交给下游解释器时。应执行 Schema 校验，使用安全对象构造，授权字段和对象，并按输出上下文编码。

两种格式都要把远程引用、URL、嵌入内容和不可信 Schema 视为需要允许列表和资源预算的数据。不要让解析器访问任意网络位置。

迁移是 Schema 映射

安全迁移应先写映射文档：

源特性 映射决策
XML 命名空间 保留 URI、映射为限定键，或拒绝
XML 属性 使用 @attributes 对象，或定义显式字段
重复元素 数组、单值/数组联合，或独立表
混合文本和子元素 有序内容列表，而不是普通字符串
空元素与缺失元素 独立哨兵或明确规范化
注释和处理指令 独立保留，或有意丢弃
XML 实体与字符数据 按安全策略解析并校验输出
JSON 数组/对象到 XML 选择元素名、根节点、顺序和命名空间

通用递归转换器无法推断所有选择。应使用领域 fixture 测试往返，并记录有意丢弃的信息。

适合 JSON 的场景

  • 以对象/数组为主的类型化 API 和事件载荷；
  • 客户端已有成熟 JSON 工具链的语言生态；
  • 不需要注释和混合文档内容的配置；
  • 主要目标是紧凑值交换的浏览器和移动应用。

适合 XML 的场景

  • 需要混合文本、标记、文档顺序或丰富元数据的文档；
  • 依赖命名空间的行业标准和 SOAP/WSDL 契约；
  • 已有 XSD、Schematron、XPath、XSLT 或签名 XML 流程；
  • 兼容性由行业或监管规范控制的集成。

两种格式也可以用于其他场景。选择时应纳入演进、校验、可观测性、安全配置、所有权和迁移成本。

常见问题

JSON 总是比 XML 快吗？

不是。结果取决于解析模式、校验、转换、压缩、载荷结构、内存和硬件。应基于生产路径测量，而不是比较格式名称或一对解析器。

XML 总是把值当字符串吗？

XML 语法层面的字符数据是文本，但 XSD 和应用代码可以把它解释为整数、日期、布尔、十进制等类型。类型来自契约和解析/校验流水线，而不是 XML 语法自动提供。

JSON 比 XML 更安全吗？

两种语法都不会自动安全。XML 需要仔细配置外部实体和资源解析；JSON 需要安全处理 JavaScript、HTML、URL、对象合并和下游解释器。两者都应执行上下文校验与授权。

JSON 和 XML 可以无损互转吗？

一般不能。命名空间、属性、混合内容、文档顺序、注释、处理指令、重复名称和类型注解可能丢失，或需要定制映射。只有在受约束且经过测试的子集内，才能证明无损。

新 API 应默认使用 JSON 吗？

JSON 常是类型化数据的实用默认值，但现有行业契约、文档模型、命名空间要求或 XML 工具链可能使 XML 风险更低。应从完整生命周期选择，而不是追随潮流。

一手来源

总结

JSON 和 XML 是不同模型，拥有不同优势、生态与失败模式。应选择符合数据或文档契约的格式，测量完整处理路径，安全配置解析器，并在共存时编写明确迁移映射。谨慎的契约比寻找一个普遍赢家更有价值。