YAML 的隐藏陷阱：从布尔值到八进制

That's a Lot of YAML

▲ 66hisamafahri69 HN 评论区
YAML 的隐藏陷阱：从布尔值到八进制

作为开发者，你是否也曾在 Kubernetes 配置中踩过 YAML 的坑？这篇文章犀利地指出了 YAML 在 DevOps 领域的诸多隐患：从将挪威缩写 'NO' 误判为布尔值，到时间戳被自动转换为秒数，再到版本号被解析为浮点数。作者幽默地调侃了 YAML 缺乏官方文档、支持注释却存在严重安全漏洞的现状，并提醒大家在 GitHub Actions 等场景中需格外小心。这些看似微小的语法细节，往往会导致生产环境的意外崩溃，是每位 DevOps 工程师必须经历的‘成人礼’。

任何使用 YAML 足够久的人，最终都会因为试图缩写挪威而付出代价。
阅读原文 →HN 评论区RSS

HN 评论区

69
  1. fodkodrasz

    YAML 本身没问题，就像 XML 当初也没问题一样。问题在于那些把它用错地方的软件开发者。我只是好奇，为什么 JSON 没招来那么多骂声，毕竟它也是个糟糕的格式：它不支持流式处理（而 YAML 支持），也不支持注释……而且大家还得用各种非标准的变通方案来实现这些功能。在我看来，Norway 比 YAML 更好。

  2. fypanto

    笑死

    其实大部分问题都源于 1.1 版本，那个版本被弃用多久了都记不清了。

    1.2 版本已经没有 'Norway' 这个坑了。

    顺便自夸一下，这就是现代 YAML 库如今该有的样子：

    https://github.com/pantoniou/libfyaml

  3. vova_hn2

    我至今仍很遗憾 JSON5 没能成为行业标准。

    与 hjson、toml 等许多其他格式不同，JSON5 并没有试图重新造轮子去搞一套全新的语法。

    相反，它把两个已经非常成熟的规范（JSON 和 ECMAScript 5.1）结合在了一起。

    我觉得这样手写起来挺舒服，同时也没有再创造一种需要你去适应的新语法。

    [0] https://json5.org/

  4. NoboruWataya

    很惊讶在替代方案部分没提到 TOML，它大概是我最喜欢的配置格式。

    我现在正在做一个项目，用 YAML 做配置（在这个场景下比 TOML 更合理），并使用 Rust 的 `serde` crate（通过 `serde_norway`）来解析它。如果你到处都用上 `#[serde(deny_unknown_fields)]`，其实也没那么糟糕。

  5. masfoobar

    我对 YAML 的使用经验有限。在我用过的几次场景里（kubernetes、docker compose 以及其他一些东西）——我实在没看出它有什么特别之处。

    它看起来就像是在一遍又一遍地重新造轮子。

    我并不是说 JSON 就完美无缺。不过，我确实比 YAML（和 XML）更喜欢它，而且喜欢得多。

    s-expressions 没能流行起来真可惜。

    (select (id name)

    (:from users)

    (:where (= name "Peter")))

    或者

    (orders

    (order

    (id 1)

    (code "aa1")

    (qty 32)))

    我知道这只是个示例，但你们懂我的意思。:-)

同日更多故事

2026-08-28