高安全场景（航天 DO-178C、汽车 ISO26262/21434）弃用 YAML，优先 XML/JSON 的核心原因是航天、自动驾驶、轨道交通这类功能安全 + 信息安全双高要求行业，选型核心标准：
无歧义、可形式化验证、解析行为确定、无隐藏漏洞、工具链可合规认证、标准原生支持 。
YAML 先天设计缺陷完全违背这些底线，XML、JSON 更贴合安全规范。
一、YAML 致命缺陷：隐式类型自动转换（最致命、会引发致命故障）
YAML 1.1（绝大多数工业 / 开源解析器默认版本）自动猜测数据类型，无强制引号约束 ，极易静默解析错误，程序不报错但逻辑完全错乱，安全系统无法容忍这种 "隐性失效"。
典型高危案例：
- 1、挪威问题：country: NO（国家码挪威）无引号 → 自动解析为布尔false；ON/Yes/off同理，配置参数被偷偷篡改；
- 2、数字歧义：port: 080 识别为八进制 = 64；version: 1.10 解析浮点数，字符串比对直接失败；
- 3、日期自动转换：time: 2026-07-08 自动转为日期对象，而非字符串 ID；
对比 XML/JSON
- JSON ：所有字符串必须双引号包裹，"NO"永远是字符串，不存在自动类型推断；数字、布尔严格区分，规则唯一（ECMA-404 标准固定）；
- XML：XSD 可严格限定字段数据类型，明确标注 string/int/bool，解析器强制校验，非法值直接抛出解析失败，不会静默篡改数据。
功能安全标准（ASIL-D/DAL-A）明确禁止不可预测、无报错的静默数据转换，YAML 天然踩红线。
二、缩进语法：容错极差，微小空格引发逻辑变更，难以审计溯源
YAML 靠空格缩进区分层级：
- 1、多 1 个 / 少 1 个空格、Tab 与空格混用，文档结构直接改变；
- 2、报错行号不准，大型配置（上百行）很难定位语法错误；
- 3、人工修改、多人协作极易引入肉眼不可见的空格缺陷；
汽车 / 航天软件要求配置文件可完整审计、每一次修改都可精准校验 ，缩进带来的隐性缺陷无法通过静态审查发现。
XML 靠成对标签、JSON 靠括号划分层级，空格 / 换行完全不影响结构，格式错误一眼识别，审计工具成熟。
三、YAML 存在高危反序列化安全漏洞（信息安全硬伤 ISO/SAE 21434）
YAML 规范支持自定义类型标签（!!python/object、!!java） ，恶意构造配置文件可在解析时执行系统命令、篡改内存、越权操作，属于严重代码注入漏洞。
即使限制安全加载器，不同厂商解析器实现差异会产生边界漏洞；
- XML：有严格安全规范 XML Signature、XML Encryption，禁止任意对象反序列化；
- JSON ：完全没有自定义对象扩展能力，仅支持基础类型（字符串、数字、布尔、数组、对象、null），不存在远程代码执行风险，嵌入式安全解析器极易实现、认证。
车载、航空设备禁止任何配置解析阶段的代码执行风险，YAML 原生扩展机制不符合网络安全合规。
四、标准化校验、形式化验证生态差距巨大（合规认证刚需）
1. XML（工业安全首选）
- 原生配套XSD XML Schema：行业成熟、标准化强校验工具，可约束：字段必填、数值范围、枚举、长度、正则、层级顺序、多重命名空间；
- 配套 XPath/XSLT、形式化验证工具，航空 / 汽车官方工具链原生支持；
- 安全标准原生依赖 XML：车载诊断 DBC、AUTOSAR 标准、航空机载接口定义全是 XML；
- 支持文档元属性、分层模块化，大型复杂系统拆分管理。
2. JSON
- JSON Schema 标准化校验，规则简单，嵌入式轻量解析库极多；
- 规范极简、唯一，跨语言解析行为 100% 统一，无版本分歧；
- 二进制序列化（CBOR）广泛用于车载通信、机载数据交互。
3. YAML 短板
- 无官方原生 Schema，校验依赖第三方工具（yamllint、自定义脚本），无统一行业标准；
- YAML 1.1 与 1.2 规范行为不一致，不同解析器（PyYAML、C 解析库、C++ 库）解析结果存在差异；
- 缺少航空、汽车认证级形式化验证工具，无法满足 DO-178C、ISO26262 工具鉴定要求；
- 主流安全标准（AUTOSAR、ARINC、IEC61508）从未将 YAML 纳入标准格式。
五、嵌入式 / 安全系统解析器实现难度与确定性
安全关键软件要求解析逻辑极简、无未定义行为、可静态代码证明（形式化证明）：
- JSON 语法极简，仅 6 种基础数据类型，无歧义语法，手写安全解析器工作量极低，MISRA C 合规实现简单；
XML 虽然冗长，但 SAX 流式解析成熟，行业经过数十年安全验证；
YAML 语法规则极其复杂：多风格混合（块式 / 行内）、多行字符串多种写法、隐式类型、特殊关键字、标签扩展；
自研嵌入式安全解析器极易遗漏边界条件，无法通过工具鉴定、安全论证。
六、可审计、可固化、不可篡改配套标准
高安全场景要求配置文件：签名校验、完整哈希固化、不可修改追溯：
- XML：W3C 标准化 XML 数字签名、加密，完整工业落地；
- JSON：JOSE（JSON 加密 / 签名）IETF 标准，车载以太网、机载总线广泛使用；
- YAML：无统一官方签名、哈希固化标准，各厂商自行实现，跨设备一致性无法保证。
七、 YAML适用在哪些场景中
仅运维、云平台、DevOps、测试脚本等非安全关键系统 （K8s、Ansible）使用，这类系统允许人工排查故障、重启服务；
但车载控制器 、飞控 、电机安全控制 、机载设备这类失效会造成人身伤亡的核心模块，行业强制禁用 YAML。
总结对比表
| 维度 | XML/JSON | YAML | 安全行业影响 |
|---|---|---|---|
| 类型解析 | 严格显式，无静默转换 | 隐式自动推断，大量歧义 | YAML 违反功能安全核心要求 |
| 语法结构 | 括号 / 标签，空格无关 | 缩进驱动，空格改变逻辑 | 审计、人工审查不可靠 |
| 安全风险 | 无代码注入能力 | 支持自定义对象，RCE 漏洞 | 不满足车载 / 航空信息安全规范 |
| 标准化校验 | XSD/JSON Schema 行业标准 | 无官方 Schema，工具碎片化 | 无法完成 ASIL/DAL 合规认证 |
| 解析确定性 | 跨语言 / 跨版本行为统一 | 1.1/1.2 版本行为不一致 | 多芯片、多设备交互存在解析分歧 |
| 工业标准支持 | AUTOSAR、DO178、IEC61508 原生支持 | 无主流安全标准采纳 | 无法通过行业准入认证 |
八、结束语
对于个人DIY、小课题研究、以及小项目的验证工程。其实适用哪个都行，但是对于要追求确定性高和稳定性强的使用场景，XML/JSON是最好的选择。一个比较明显的变化就是在ROS1的各个开源代码中，YAML的配置文件大量被应用，但是在ROS2的代码文件中，YAML使用频率大幅降低，相应的XML/JSON的配置文件被绝大多数场景使用。