TOML（Tom's Obvious, Minimal Language）是为配置文件设计的序列化格式，目标是简洁、可读且易于手写。常用于项目配置（如 Rust 的 Cargo、Python 的 Poetry、各类工具的配置文件）。下面概要说明其特性、示例及与 JSON 的对比，帮助选择合适场景。
核心特点（简要）
- 面向配置：设计用于人类编辑的配置文件。
- 支持注释：使用
#。 - 明确的原生类型：字符串、整数、浮点、布尔、日期时间、数组、表（table）。
- 表与表数组：便于层级组织配置。
- 可读性高：语法更接近 INI，但类型更丰富。
基本语法示例
toml
# filepath: example.toml
title = "示例配置"
owner = { name = "Alice", dob = 1979-05-27T07:32:00Z }
[database]
server = "192.168.1.1"
ports = [ 8001, 8001, 8002 ]
enabled = true
ratio = 0.75
[[products]]
name = "Hammer"
sku = 738594937
[[products]]
name = "Nail"
sku = 284758393
color = "gray"
对应的 JSON（同语义）：
json
{
"title": "示例配置",
"owner": { "name": "Alice", "dob": "1979-05-27T07:32:00Z" },
"database": {
"server": "192.168.1.1",
"ports": [8001, 8001, 8002],
"enabled": true,
"ratio": 0.75
},
"products": [
{ "name": "Hammer", "sku": 738594937 },
{ "name": "Nail", "sku": 284758393, "color": "gray" }
]
}
与 JSON 的对比（要点）
- 可读性
- TOML：面向人类，允许注释，表结构清晰，适合手动维护配置。
- JSON：紧凑、标准化但不支持注释（配置场景常被诟病）。
- 类型与语义
- TOML：内建 datetime、明确定义整数/浮点/布尔/数组/嵌套表。
- JSON：基本类型（string/number/boolean/null/array/object），日期通常以字符串表示并需约定格式。
- 可写性（手工编辑）
- TOML 更友好（注释、表语法、行内表等）。
- 生态与工具支持
- JSON：极其普及，原生支持于多数语言（尤其 JavaScript），适合数据交换和 API。
- TOML：配置使用广泛，解析器越来越多，但在某些语言/平台的支持不如 JSON 全面。
- 机器可处理性 / 互操作性
- JSON 更通用、轻量、网络传输更常用（很多网络协议以 JSON 为默认）。
- TOML 更适合作为静态配置文件，而非频繁网络交互的序列化格式。
- 注释与可维护性
- TOML 支持注释，便于说明配置项；JSON 不支持（需要外部文档或自定义字段）。
- 严格性与规范
- TOML 标准严格（v1.0.0），对类型/转义等有明确定义。
- JSON 标准成熟且广泛实现。
何时使用哪个
- 选择 TOML：
- 配置文件需多人手工编辑、希望内置注释和日期类型（例如项目配置、工具配置）。
- 需要层级清晰的可读配置文件。
- 选择 JSON：
- 数据交换（API、前后端通信）、日志或需要广泛兼容性的场景。
- 需要最广泛的库与语言支持，或嵌入到 JavaScript 环境中。
优点/缺点快速概览
- TOML 优点：可读性高、支持注释、类型丰富（datetime）、表语法直观。 缺点：生态和解析器不及 JSON 广泛；用于网络传输场景不够普及。
- JSON 优点：极度普及、格式紧凑、语言原生支持（JS）。 缺点：不支持注释、日期需自定义约定，手写维护时可读性和可注释性较差。
工具与注意事项
- 常见解析库：各语言均有 TOML 解析器（toml-rs、toml for Python、toml-js 等）。
- 版本：使用 TOML v1.0+ 时注意解析器是否兼容。
- 与环境变量/模板结合使用时，配置文件往往需要转换或合并，选择前确定生态支持。
总结：TOML 是面向配置文件的优秀选择（注释友好、类型丰富）；JSON 则是数据交换与平台互操作的首选。根据用途（配置 vs 数据交换）、可维护性与生态支持来决定使用哪种格式。
