XML被称为“人机都可读”，因其用纯文本和标签化结构表达数据，既便于人类直观理解内容与层级，也支持程序按规则解析；它兼顾协作与自动化需求，适用于需长期维护、多方审阅的场景，但体积大、解析开销高，轻量交互中不如JSON高效。
XML被称为“人机都可读”，是因为它用纯文本、标签化结构表达数据，既能让开发者一眼看懂内容和层级，也能被程序按规则解析提取。这种设计不是为了取悦某一方，而是兼顾协作与自动化的基本需求。
人可读带来的实际优势
人类能直接打开XML文件，不用工具就能大致理解数据含义和组织方式。比如一个配置片段：
这种写法直观清晰，修改时不容易出错。具体好处包括：
- 排查问题快——错误常体现在标签不闭合、嵌套错位等，肉眼就能发现
- 跨角色协作顺——产品、测试、运维都能看懂配置或接口返回，减少沟通成本
- 文档即数据——不需要额外写说明文档，结构本身自带语义（如
<invoice></invoice>比{"t":"inv","d":...}更直白） - 支持注释——可以用
<!-- 这里是测试环境配置 -->写说明，JSON做不到
机可读但不等于高效可读
机器确实能解析XML，但“可读”不等于“好读”。它的结构规范性强，代价是解析链路长、资源消耗高：
- 必须完整加载才能构建DOM树，大文件容易内存溢出
- 标签重复出现（如
<item>...</item>），同样数据比JSON体积大30%–50% - 解析器种类多（DOM/SAX/StAX），API风格差异大，写代码时容易踩坑
- 浏览器兼容性差——老版本IE和某些移动端需额外处理命名空间或编码
可读性引发的权衡取舍
正因为“看起来清楚”，XML常被用在需要长期维护、多方审阅的场景，比如：
- 企业级配置文件（Spring的applicationContext.xml）
- 行业标准交换格式（医疗HL7、金融FIX、出版EPUB）
- 带复杂元数据的文档（SVG、Office Open XML）
但反过来，如果只是前后端传个用户列表，用XML就显得笨重——JSON一行能写完的，XML要七八行，还多一堆引号和转义。这时候“人可读”的优势被传输开销和解析延迟盖过了。
基本上就这些。可读性不是万能钥匙，关键看谁在读、读多久、读多少次。
