YAML转JSON后001变成1？用KKCE检查配置值的类型
YAML 转 JSON 时，未加引号的值可能被解析为数字或布尔值，编号前导零因此可能丢失。对区域代码、版本标签等必须保留原样的值，应明确用字符串表达，再观察转换结果。KKCE YAML/JSON 互转工具适合快速查看常见配置在两种表示之间的变化。
先问字段是什么，再决定如何写
配置中的001可能是区域代码，也可能是一个整数的展示形式。前者与002、A01并列，通常应该保留字符串；后者只是数值1，保留零没有业务意义。转换之前先由字段所有者明确含义，比事后在输出里手动补零更可靠，也避免下一次保存时再次丢失。
此次在输入区填写 service: KKCE、带双引号的 region_code: "001"、enabled: true 和 retries: 3，并增加两项 labels 列表。点击“YAML → JSON”后，输出中 region_code 保留 "001"，enabled 为布尔值，retries 为数字，labels 为数组。该结果展示了同一份配置中不同类型可以被分别保留。
2026 年 11 月 7 日在 KKCE 官网实际操作，画面中的数据仅作方法演示。
交付配置前应核对的值
| 配置角色 | 期望类型 | 需要观察的输出 |
|---|---|---|
| 地区或产品编码 | 字符串 | 引号和前导零是否保留 |
| 功能启停开关 | 布尔值 | 是否仍为 true 或 false |
| 重试次数 | 非负整数 | 是否落在系统允许的范围内 |
| 标签集合 | 数组 | 元素顺序与元素类型是否一致 |
语法转换本身不知道业务限制。例如 retries: -1 在文本层面可以是一个数字，但目标服务可能只接受0至5。enabled 的真假也不代表功能已经在生产启用：实际部署时还可能受到环境变量、启动参数或更高优先级配置覆盖。排查问题时，应同时记录最终加载结果。
缩进变化为何会改变配置结构
YAML 的缩进承担层级表达。同名字段被缩进到不同父级后，文字虽然几乎一样，结构却已经改变。转换后展开 JSON，检查某个键究竟属于根对象还是子对象，是核对缩进含义的一种直观办法。尤其在复制多段配置时，应留意编辑器是否混入制表符。
基础映射、列表和普通标量适合在线快速检查；复杂锚点、别名与自定义标签则需要完整解析器和目标程序确认。KKCE 页面已说明使用基础解析逻辑，因此不能把一次转换成功理解为覆盖所有 YAML 语法。对高级配置，保留原文和实际加载日志更有帮助。
反向转换时还要保留什么证据
从 JSON 转回 YAML 之前，先保存业务字段对照表。注释、排版习惯与引号风格不一定能往返恢复，不能用最终文本与原稿逐字相同作为唯一标准。更合适的做法是检查字段路径、数据类型与值是否符合约定，再在目标服务的校验模式中验证可加载性。
给所有值加引号最省事吗？
这样可能把布尔开关和重试次数也改成字符串，反而违背目标字段类型。应按字段含义选择表达方式，不宜统一处理。
能直接处理包含生产口令的配置吗？
演示和联调可以先替换凭据、账号与内部资源名称，只保留结构和必要类型。本文使用的是自建无凭据样本，未导入真实生产配置。
KKCE 的互转结果能让类型变化一眼可见。把它用于迁移前的样本检查，再配合目标环境的正式校验，可以更早发现“配置内容看似没变，程序读取方式却变了”的问题。
资料核对日期：2026 年 11 月 7 日。资料来源与工具入口：
