为什么从 TOML 转到 YAML？
TOML 是一种非常适合手动编辑的配置格式，但许多生态系统——Kubernetes、GitHub Actions、GitLab CI、Ansible、Docker Compose——都使用 YAML。当某个工具或管道只接受 YAML 时，你需要在不改变配置含义的前提下翻译你的 TOML 配置。这两种格式描述的是相同的基础数据模型（映射、列表和标量的树），因此从 TOML 到 YAML 的转换是无损的。
表格如何变成嵌套
TOML 的表头变成了 缩进的 YAML 键。TOML 使用扁平的 [section] 标记，而 YAML 使用缩进来表示相同的层次结构：
title = "My App"
[database]
host = "localhost"
port = 5432
title: My App
database:
host: localhost
port: 5432
[database] 表头变成了 database: 键，其子项缩进两个空格。带点的 TOML 表头如 [a.b.c] 会变成三层 YAML 缩进。
表格数组变成映射列表
TOML 的双括号表格数组映射为 YAML 的 映射序列：
[[steps]]
name = "build"
run = "make"
[[steps]]
name = "test"
run = "make test"
steps:
- name: build
run: make
- name: test
run: make test
每个 [[steps]] 块变成一个 - 列表项。这正是 CI 系统期望的任务步骤的形状，因此 TOML→YAML 转换在管道工作中频繁出现。
引号和缩进陷阱
YAML 对空白敏感，并且有一长串值如果不加引号会改变含义。转换器会处理这些，但了解为什么输出会对某些字符串加引号会有所帮助：
- 伪装成布尔值的字符串——
yes、no、on、off、true、false在 YAML 1.1 中被解释为布尔值。字符串"yes"必须加引号才能保持为字符串。 - 数字和版本号——
1.10会被解析为数字1.1；像"1.10"这样的版本字符串需要引号。 - 前导零和冒号——像
08:00或0755这样的值可能被误读；加引号可以保持字面值。 - 缩进必须是空格，绝不能是制表符。生成的文件使用一致的两个空格缩进。
验证结果
由于 YAML 对格式敏感，在将输出提交到管道之前要验证它。快速往返检查——解析 YAML 并将结果数据结构与原始 TOML 进行比较——可以捕获任何引号意外。大多数 CI 平台也提供配置检查器；转换后运行一次。
常见问题
TOML 到 YAML 的转换是无损的吗？ 是的。两种格式都表示相同的映射/列表/标量模型，并且 TOML 中可表达的一切都有 YAML 等价物，因此朝这个方向转换不会丢失数据。
为什么转换器会对某些字符串加引号而对其他字符串不加？
为了保护那些 YAML 会重新解释的值——yes/no 作为布尔值，1.10 作为数字，像 08:00 这样的时间。加引号强制它们保持为字符串。
我可以直接将 TOML 转换为 GitHub Actions 或 Kubernetes 文件吗？ 数据结构转换得很干净，但每个平台都期望特定的顶级键。先转换，然后调整键名以匹配目标模式。
将你的 TOML 粘贴到上面的转换器中，即可获得干净、正确缩进的 YAML，准备好用于 CI 管道和 Kubernetes 清单。