生成 YAML 时保留 JSON 数据类型

直接映射

对象转换为映射，数组转换为序列；string、number、boolean 和 null 保持原本含义。

JSON 对象键本来就是字符串，可作为普通 YAML 键输出。

何时使用引号

"true"、"null" 或 "0012" 这样的字符串必须继续保持文本。引号可以防止消费端把它们解释成布尔值、null 或数字。

引号也能保护空格、冒号和特殊字符。

数字与精度

JSON 语法不区分整数和浮点数，目标系统可能有不同的数值范围。

应核对超大数字、指数写法以及实际作为标识符使用的数值。

可靠的分步处理流程

应把YAML 中的 JSON 类型视为一次有明确输入、预期结构和目标系统的数据转换。先复制原文，在改变表示方式前完成验证，再提取一个足以复现问题的最小样例。这样才能把语法错误与数据模型或业务错误分开。

每次只做一项修改，并在每次修改后重复同一套验证。自动化流水线遇到解析错误时应直接失败，不能发布残缺或猜测修复的结果。需要审计时，应把原始输入和生成文件一同保留。

• 先选取具有代表性的输入并保留原始副本，以便审查差异或重复执行转换。
• 不要只看渲染后的文字，还要检查解析结构；键名、标量类型、数组顺序和 null 才是下游程序真正收到的数据。
• 在真实目标系统中测试结果，并记录项目依赖的解析器、模式、编码和格式假设。

实例与验证方法

下面的示例刻意保持简短，便于逐项核对。处理真实文件时也应检查每个键、标量类型、数组顺序以及嵌套边界，而不是只确认页面显示“成功”。

转换或压缩成功，只能证明源文本可以被解析。还应比较操作前后的结构化值，并使用生产环境真正采用的库或平台重新读取结果，才能发现实现差异。

stringId: "0012"
enabled: true
count: 12
empty: null

限制与边界情况

YAML 中的 JSON 类型的难点通常来自“语法有效”和“业务可用”之间的差别。解析器接受的数据仍可能缺少字段、含义模糊、体积过大，或不符合目标系统的模式。

不要盲目修复或规范化陌生文件。重复键、隐式类型、别名、数字精度、Unicode、换行符和超大输入都需要明确策略；目标系统的规则更严格时，应以目标规则为准。

生产环境检查清单

发布前至少测试正常文档、空值、深层嵌套、非 ASCII 文本和一个故意损坏的样例。如果其他系统必须复现完全相同的输出，还应记录工具或依赖库版本。

当数据参与构建、部署、API 或配置时，应把验证加入持续集成。上线前审查差异并保留回滚副本，上线后观察第一个真实使用方，不能把“语法通过”等同于“运行正确”。

• 先选取具有代表性的输入并保留原始副本，以便审查差异或重复执行转换。
• 不要只看渲染后的文字，还要检查解析结构；键名、标量类型、数组顺序和 null 才是下游程序真正收到的数据。
• 在真实目标系统中测试结果，并记录项目依赖的解析器、模式、编码和格式假设。

相关问题