同等结构的数据，XML体积通常是JSON的2.5到4倍；gzip后仍大1.8–2.5倍，主因是标签成对、属性重复、文本强制包裹等语法冗余。
XML比JSON大多少？实测数据差异在2.5–4倍之间
直接说结论：同等结构的数据，XML体积通常是JSON的2.5到4倍。这不是理论估算，而是用真实业务数据（含嵌套、属性、中文、空格）跑出来的均值。压缩后差距会缩小，但XML仍稳输——gzip后通常还大1.8–2.5倍。
为什么XML更占空间？三个硬伤全在标签语法里
XML冗余不是“多写几个字”那么简单，是语法机制决定的：
-
<user></user>和成对出现，JSON只需一个"user"字符串加冒号 - 属性写成
<item id="123" type="admin"></item>，JSON对应{"id":"123","type":"admin"}—— XML属性名重复两次，还要引号和等号 - 文本内容强制包裹，
<name>张三</name>比"name":"张三"多出10个字符（含尖括号、斜杠、引号、冒号、逗号）
实测时怎么避免被“美化格式”骗？
很多对比测试结果虚高，是因为用了带缩进/换行的XML（比如浏览器里直接保存的）。真实传输用的是无格式XML：
- 生成XML时关掉
prettyPrint或indent选项（如Pythonxml.etree.ElementTree默认不缩进） - JSON别手动加空格，用
json.dumps(..., separators=(',', ':'))压到最紧凑 - 中文字符在UTF-8下两者都是3字节，不用特殊处理；但XML声明
<?xml version="1.0" encoding="UTF-8"?>是纯额外开销，传输时通常不带
什么时候XML体积劣势反而不重要？
不是所有场景都卡体积。如果满足以下任一条件，体积差可以忽略：
- 数据极小（比如单条配置：
<config debug="true"></config>vs{"debug":true}，差不到10字节） - 走HTTP/2或gRPC，头部压缩（HPACK）能大幅削减重复标签开销
- 服务端已用gzip且QPS很低，CPU比带宽更不紧张
- 你根本没在传数据——比如只用XML做XSD校验或XSLT转换，根本不序列化传输
真正要警惕的是移动端弱网+高频小报文场景：一个300字节的JSON请求，换成XML可能飙到1KB以上，重传概率和首包延迟都明显上升。
