xml和json的区别是什么？做后端开发的同学几乎每天都和这两种数据格式打交道，但真要说出个所以然来，很多人只能憋出一句“json更轻量”。这话没错，但不够全面。xml诞生于上世纪九十年代末，设计目标是描述文档结构并实现跨平台数据交换；json则是2001年前后由Douglas Crockford推广起来的轻量级数据格式，最初服务于JavaScript生态。两者解决的其实是同一类问题——把结构化数据从A处搬到B处，只是设计哲学完全不同。下面从七个维度逐一拆解。
一、语法结构：标签体系 versus 键值对
xml是一种标记语言，全称是eXtensible Markup Language，它用开闭标签包裹数据，标签可以层层嵌套，还能携带属性。json则是JavaScript Object Notation的缩写，核心就是对象、数组、字符串、数字、布尔值和null这几种类型的组合，用大括号表示对象，方括号表示数组。
同一个用户信息，xml大概长这样：
<user id="1001">
<name>张三</name>
<age>28</age>
<tags>
<tag>java</tag>
<tag>go</tag>
</tags>
</user>换成json则是：
{
"id": 1001,
"name": "张三",
"age": 28,
"tags": ["java", "go"]
}直观感受很明显：xml必须写开标签和闭标签，标签本身可以携带语义（比如id属性）；json则是纯粹的键值结构，类型信息直接体现在值的形式上，数字不用引号，字符串必须用双引号。json的语法来自JavaScript的字面量表示法，所以在浏览器里可以直接被解析，这是它早期流行的先天优势。而xml有一套严格的规范体系，包括DTD、Schema、命名空间等，功能强大但学习成本也高。
二、数据体积与传输效率
json在体积上几乎是碾压式胜出。从上面的例子就能看出，xml每个数据项都要写两遍标签名，加上属性引号、命名空间声明，冗余内容能占到整个报文的百分之三十以上。json只保留键名和值，分隔符就是冒号、逗号和括号，同样的数据往往只有xml的一半甚至更小。
在弱网环境和移动端场景，这个差距会被放大。一个接口返回几百条记录，xml格式可能是200KB，json可能只有80KB，流量省了一大半，传输耗时也相应缩短。当然如果对体积极其敏感，还可以上gzip压缩，压缩后两者差距会缩小，但json的基线仍然更低。这也是为什么现在主流的RESTful API几乎清一色用json响应，毕竟每一次请求省下的字节都是实打实的用户体验。
三、解析速度与开发体验
解析效率方面，json结构简单，主流语言的json库（如Java的Jackson、Go的encoding/json、Python的json模块）都能做到接近O(n)的线性解析，配合流式解析器处理大文件也不吃力。xml解析则分为DOM和SAX两种模式，DOM要把整棵文档树加载进内存，小文件无所谓，大文件就容易内存吃紧；SAX虽然省内存，但基于事件回调，写起来相当繁琐。
开发体验上json更是友好。以JavaScript为例，前端拿到json字符串后一句JSON.parse()就变成对象，直接点取属性；而xml还要借助DOMParser逐层遍历节点，代码量翻了好几倍。其他语言里json与语言原生数据结构的映射也更直接，Python的dict、Go的struct、Java的POJO都能无缝转换。
四、可读性与数据类型表达能力
可读性这一点见仁见智。xml的标签自解释性强，比如<price>一看就知道是价格，配合注释还能进一步说明， xml是支持注释的，而json标准不支持注释，这一点让json在配置文件场景颇为尴尬，后来才出现了json5、yaml等替代方案来弥补。
数据类型表达上两者各有短板。json原生只有number类型，不区分整数和浮点数，精度超过一定位数的大数（比如Java的long类型超过2的53次方）在JavaScript里会丢失精度，这是无数踩过坑的开发者的血泪教训。xml则是“什么都是文本”，类型信息全靠Schema约定或者接收方自行判断，80分还是"80"没有语法层面的区别。严格来说，xml的Schema校验能力比json的Schema成熟得多，XSD能定义非常复杂的结构约束，这在金融、医疗等强校验领域很有价值。
五、扩展性与元数据能力
xml的扩展能力是它的核心优势。命名空间机制可以让不同来源的xml片段合并而不产生标签冲突，SOAP协议正是基于这一特性构建的，一个信封里同时携带报文头、报文体和错误信息。属性和子元素的区分也给了设计者更灵活的表达空间，还支持CDATA段存放原始文本、处理指令等高级特性。
json没有命名空间的概念，如果两个系统返回的字段重名，只能靠字段命名约定来规避，比如都加上前缀。json的扩展全靠程序员自己设计结构，遇到“同一个字段可能是对象也可能是数组”这种历史遗留设计，反序列化代码就会写得很难受。所以在协议层面需要强结构定义和版本演进的系统里，xml加上XSD的组合依然稳固。
六、安全性与常见攻击面
安全性上两者都有各自的坑。xml最著名的是XXE攻击，也就是外部实体注入，攻击者在xml中声明外部实体指向本地文件或内网地址，如果解析器开启了外部实体支持，服务器的敏感文件就可能被读取，甚至造成SSRF。防御方式是禁用DTD和外部实体，Java里配置相应的feature即可：
// 使用DocumentBuilderFactory时关闭外部实体
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setXIncludeAware(false);
factory.setExpandEntityReferences(false);json的主要风险在于反序列化漏洞和JSON Hijacking。有些框架直接把json反序列化成对象，如果攻击者能控制报文内容，可能触发任意代码执行，典型如Java的fastjson历史漏洞。相对而言json的攻击面更容易控制，关掉危险特性即可，而xml的实体机制天然更复杂，需要小心的配置点更多。
七、适用场景与选型建议
说了这么多，到底该怎么选？给出几条实践建议：
- 前后端交互、移动端API、微服务间通信：优先json，生态成熟、体积小、解析快，配合OpenAPI文档工具链完整。
- WebService（SOAP协议）、跨机构报文交换、EDI：继续用xml，银行业和大型企业的对接规范大多基于xml，改造成本远高于收益。
- 配置文件：java的Spring用xml配置的比例越来越低，被注解和yaml取代；Android的布局文件依然是xml；office文档的底层格式（docx、xlsx）本质是zip包裹的xml。
- 需要强校验的领域：xml配合XSD更成熟，不过json schema也在快速发展。
还有一个容易被忽视的点：两者混合使用时注意字符编码和转义规则。xml里的&、<必须转义成实体，json里的双引号、反斜杠也要按规则处理，跨格式转换时这些细节最容易出错。总结一句话：json赢在了轻量易用的时代需求上，xml则胜在结构严谨和生态深厚，技术选型没有绝对的对错，看场景下菜才是正解。