SOML：告别 YAML 类型猜测，一个面向人类的配置格式

SOML 的核心设计：从语法到类型的确定性映射

SOML 的全称是 Sindre's Objectively Marvelous Language，官方定位是 A config format for humans，人类可写、人类可读 来源：HH。我先把它的语法特点捋一遍。顶层不需要花括号，键名不需要引号，换行替代逗号，注释几乎可以出现在任何位置。这些降低的是书写负担，属于舒适度层面的改动。

真正硬核的改动在类型系统上。SOML 里，一个值的类型由它的语法决定，不由它的内容决定。'123' 是字符串，123 是整数，不存在"这个字符串看起来像数字所以按数字处理"的空间。时长和日期是原生值，timeout: 30s 里的 30s 会被解析成时长对象，而不用像 YAML 那样面对 timeout: 30 时猜单位是秒还是毫秒 来源：HH。路径和正则表达式不需要转义，长文本放进块字符串，这一套下来配置文件里的反斜杠噪音能少很多。

SOML 还规定了一个规范形式和一套共享一致性测试套件。不同语言实现读取同一个文件，得到的结果必须一致 来源：HH。这一点重要，因为配置格式的另一个痛苦就是实现之间的行为差异，同一份 YAML 在 PyYAML 和 Ruby 里解析出不同类型的情况并不少见。

与 JSON/YAML 的对比：多源交叉验证的痛点与改进

JSON 的毛病是舒适度太低。引号、逗号、花括号布满整个文件，写配置像是在写代码，而且不支持注释，没法在配置里解释某个参数为什么这么设。YAML 的毛病是清晰度不足。列表标记、嵌套缩进、从内容推断类型，这些设计带来的后果就是 country: no 被解析为布尔值 false，version: 3.10 被解析为 3.1 来源：HH。我在生产环境见过因为 3.10 变成 3.1 导致版本检查失败的案例。

SOML 的定位是同时提供 JSON 的严格性和 YAML 的舒适性，并且不猜类型 来源：HH。仓库里有一份对比文档 comparison.md、一份 FAQ、一份规范说明 spec.md，还有一套 conformance 测试目录。从文档结构能看出，项目对规范严谨性和跨实现一致性是认真的 来源：HH。

不过有一个事实需要说清楚。作者给规范标注的是 Draft spec，欢迎反馈 来源：HH。这说明格式还在迭代，语法细节可能还会变。对一个还没稳定下来的配置格式，我的态度是谨慎观察。

从 HN 讨论到生态现状：一个值得关注的配置格式新选项

项目在 Hacker News 上有一条讨论帖，目前 1 分、0 条评论 来源：HN。这个热度说不上高，但至少说明格式刚进入开发者视野，还没形成社区声量。仓库当前只有 1 个提交，包含 benchmark、conformance、media 等目录 来源：HH。

拿它跟已有的 TOML 和 JSON5 比一下。TOML 在类型上有自己的规则，JSON5 是 JSON 的宽松版。SOML 的差异化亮点集中在几个地方。日期和时长作为原生类型，正则和路径无需转义，类型的确定完全来自语法 来源：HH。

对于开发者来说，问题只有一个。下一个项目要不要用它。我的答案是，如果项目对配置有复杂需求，比如需要时长、日期、正则，SOML 的语法确实能省掉不少心力和转义噪音。但考虑到它只有 1 个提交、规范还是草案，我不会在依赖它的生产项目里冒险。我会把它记下来，等 conformance 测试覆盖更多语言实现、版本号过了 1.0 再说。

原文：

SOML: A Config Format for Humans · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月28日