一个服务的配置文件用什么格式（比如 xml, json, yaml）比较好？

[chesha1]

很多服务需要一个配置文件，有一些常见格式：

• xml: java maven ，这个是我觉得最鬼畜的，可读性极差
• json: 很多前端相关的服务的配置
• yaml: k8s 喜欢用这个
• toml: 感觉比较小众，我用过的服务中，只有 cloudflare 用这个
• 纯文本: 比如 CMakeLists.txt ，感觉年代久远的服务会更喜欢直接用文本

一个服务用什么格式的配置文件，这个有什么考量吗？用什么比较好？

[summerwar]

用啥都可以，你最熟悉啥用啥就行了，都是读取文件，然后把配置拉到代码里

[dreamk]

toml 是目前最先进的配置文件格式

[chendy]

熟悉啥用啥，不知道用啥就 json
反正逻辑都是一样的，读文件，反序列化，用

[0o0O0o0O0o]

其实我觉得你可以都用，我就很喜欢同时支持命令行参数, env, yaml 和 json 的项目

[lizhien]

@dreamk 不支持直接写数组啊

[dcsuibian]

选择 yaml ，选择成功

[kirory]

还有 .ini, .env

[Hopetree]

yaml 是目前最好的配置格式，就相当于 markdown 格式一样的存在

[aloxaf]

简单的用 toml ，复杂的用 yaml
json 、xml 这种不是给人读的
CMakeLists.txt 这种属于 DSL 了

[cwcc]

如果只是读取的话，我个人 yaml 、json 是最推荐的。json 的好处就是兼容性极广，缺点就是不能注释且比较冗余。yaml 的好处就是可读性强且兼容 json ，缺点就是写的话比较混乱。toml 个人觉得有一定门槛但未来可期，ini 太过简单，xml 适合同时读写的复杂结构。

[IvanLi127]

我选 toml ，如果没复杂的嵌套结构，还是环境变量和 .env 文件比较舒服。如果需要被程序修改的需求，我选 yaml 或 json 。

[flyqie]

我个人环境变量、.env 、.ini 写的都比较多，再加上不喜欢那种缩进，一直很偏好 toml

[Trim21]

yaml 或者 toml

[pb7412221]

json 是最简单最容易的 唯一的缺点不能写注释 在 json5 中也解决的

[pb7412221]

@cwcc json5 可以写注释了

[Philippa]

支持楼上，选择 json 。因为 json 简单易懂，所有人都有相关基础，是最好用的。
toml 有点冷门，很多人不熟悉怎么用。单是先进是不够的。
yaml 就算了吧，你看看 k8s 的那堆文件还有 nindent ，缩进错一丢丢都不行，偶尔字符串偶尔数字，array 表达让人迷惑。

[agagega]

扩展性：XML>YAML>JSON>TOML
安全性：TOML>YAML>JSON>XML
人类读写：YAML>TOML>JSON>XML

苹果有个叫 pkl 的开源项目，大致相当于给不同的配置文件格式准备的配置文件，你可能会感兴趣

至于 CMakeLists.txt ，即使再怎么吹 modern ，本质上还是一个奇怪的命令式语言，用它还不如用 Lua 或者 Ruby 正经搞个 DSL ，我宁愿写 XML 也不想写它

[kenvix]

我不知道为什么这么多人喜欢 yaml 。这玩意简直就是一坨屎，我永远不知道当前缩进对的是哪里，这个缩进有没有问题。IDE 也猜不到想表达这块代码的意图位置是哪里。
但凡写过几百行的 yaml 应该和我有同感

[kenvix]

如果是几百行甚至上千行以上，有各种复杂逻辑结构的，你就应该用 XML 。明确的作用域和结尾复述对人类心智真的很友好。
如果比较简单，那就 TOML 。
如果极其简单，那就.env

yaml 适合 100 行以下规模，超过这个我看见就恶心

另外 hocon 也可以考虑下

[GeekGao]

参考：

[daimaosix]

我比较喜欢 yaml

[baobao1270]

选你用的语言
如果用的 JavaScript ，那就用 js 文件做配置
如果用的 Python ，那么就用 py 文件作为配置
直接 code as configuration

[dcsuibian]

@pb7412221 JSON5 不是 JSON 的新版本，JSON 已经定死了，JSON5 是一种新的数据格式。相对来说很冷门，而且得引入新的解析器

[flyqie]

@agagega #17

人类读写在缩进上感觉 toml 要好于 yaml 。

[lrh3321]

手写 toml 不容易犯错误。yaml 在编辑器里写也还好。

[fenglala]

推荐 json5 ，解决了 json 好多弊端，注释什么的都没问题。量大的话不推荐 yaml ，在公司见了上万行的 yaml 格式 git 仓库配置文件，几乎完全不可读，加一行加到哪都很难找。

[Pony69]

简单 toml ，复杂 yaml

[henix]

最简单的直接用环境变量
没有复杂嵌套的用 ini
复杂的用 json5 或 json
不推荐 yaml ，这玩意一旦规模上去之后，可读性大幅下降。而且 spec 相当复杂，不同语言实现出来的 yaml parser 可能有功能上的差异，导致同一个配置文件，无法在不同语言之间迁移

[zhuangzhuang1988]

用 Python ，lua 当配置文件啊。

[lisxour]

ini toml yaml .env 这几个都是对人类比较友好的，好改很多，结构也比较扁平，json 、xml ，可以存，但是如果经常需要人工修改的场景不建议用

[lisxour]

@lizhien 不支持直接写数组啥意思，xxx = ["a", "b"]就是数组结构啊

[abcbuzhiming]

@kenvix 因为 k8s 用 yaml 这东西，而 k8s 用这东西的核心原因是，k8s 工程师写配置文件的量非常大，几万行的配置文件和家常便饭一样。典型的写多读少。对于他们来说，节省几个字符串带来的收益海了去了，所以 yaml 才是这个样子。
但是对但部分其它人来讲，配置文件永远是读多写少。yaml 这种读起来一泡污的语法就一点都不友好了

[abcbuzhiming]

@GeekGao 这上面写错了，yaml 根本就不易读，人眼的生物特性，更适合横向扫描，而不是纵向位移。这就决定来了 yaml 读起来一点都不友好。而且 yaml 之所以设计成这样就是因为 k8s 的配置代码量非常大，所以少写一个 key 的收益就特别大。yaml 是少见的专门针对写多读少环境的配置语法

[lizhien]

@lisxour 这样

[
1,2,3
]

[GeekGao]

@abcbuzhiming 我写了很多年 Python ，我认为 YAML 易读。 这个理由很简单，就像你 “这上面写错了，yaml 根本就不易读” 这句话讲的很轻松那样。

[wheat0r]

如果配置不是太复杂，toml 挺好用，而且 toml 并不算小众，传统软件的配置文件都是这个风格的，只是名字不叫 toml 。
yaml 的易读程度和屏幕高度正相关，在 16:9 屏幕上就是屎，9:16 屏幕上就好不少。

[abcbuzhiming]

@GeekGao 我给了理由，不是随便轻松的讲话，人眼的特性就更适合横向扫描。况且你是不是觉得 python 和 yaml 都是有缩进，就觉得这两个玩意一样？你见过 yaml 子项的数量多到可以横跨整个屏幕高度的情况没？

[GeekGao]

@abcbuzhiming 我还没有遇到感觉很复杂的 case ，我遇到的最复杂的例子是 k8s depolyment 的配置，几百行。
问题是我不需要修改所有配置，所以也感受不到你所述 “横向扫描” 困难的问题。

[abcbuzhiming]

@GeekGao 我前面说了，yaml 这个东西之所以被 k8s 广泛采用，就是因为 k8s 的工程师动不动就要些几万行的配置文件。在这种数量级下，同样的配置项，少写一个 key 就成为了收益性很高的一件事。所以 k8s 才选了这个格式作为自己的配置文件。
你自己只需要写几百行 k8s 配置，那你一个大类下面有几个子类不得了了，那自然是体会不到这玩意难读的。实际上国外社区已经不止一次抨击过 yaml 作为 k8s 的配置文件“难以阅读”了。就在于我说的，它们说的这种“难读”的 yaml ，一个大类下面子类的数量，多到可以横跨好几个屏幕高度。看着看着眼睛就花了

[GeekGao]

@abcbuzhiming "一个大类下面子类的数量，多到可以横跨好几个屏幕高度。" 有在线的例子可以分享吗 ？ 我去感受一下

[abcbuzhiming]

@GeekGao 我手上并没有，但是老外的社区说过不止一次这个问题，想来不是空穴来风

[iorilu]

简单的就是.env, 其他都用 toml

[mark2025]

@kenvix k8s 那些上百行的 yml 的确很恶心，这种场景用 toml 似乎好得多

[mark2025]

@kenvix 可为啥对 py 的缩进很多人就接受呢。 哈哈～～～

[chinni]

adguard 的 yaml 配置 我后台里配置了几千条记录 然后打开配置文件 基本没法看

[X_Del]

https://noyaml.com/ 解释的很明白了，为什么不要用 YAML 。
YAML 看起来很简单，实际上非常复杂，很多东西都藏在水下：

- YAML 1.1 中 true 和 false 有 22 种表达方式（ https://yaml.org/type/bool.html ）
- 多行字符串到底有多少种写法（ https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in-yaml-over-multiple-lines/21699210#21699210 ）
- 字符串不严格要求引号，这个例子来自 https://www.arp242.net/yaml-config.html

```
python: 3.5.3 # => 字符串 "3.5.3"
postgres: 9.3 # => 数字 9.3
```

- 由于 YAML 1.2 规范过于复杂，几乎没有一个 YAML parser 能完美地实现 YAML 1.2 （ https://matrix.yaml.info ）

[ns09005264]

bspwm 的配置文件是 shell 脚本，bspwm 本身是 daemon 类型的软件，通过客户端 bspc 与 bspwm 通信实时变更相应的配置。所以可以把一堆 bspc 的操作命令放到 shell 脚本里执行，就相当于配置了。

类似的还有:
neovim 是用 lua 语言作为配置
nixos 是用 nix 语言作为配置

[kenvix]

@GeekGao #35 我写了 8 年 java （ xml 宇宙）、7 年 python （缩进宇宙）、4 年 kotlin （ dsl 宇宙），我认为 yaml 和 python 可读性都是一坨屎。作用域对人类不明确，特别是从外面抄代码时，IDE 根本不能把代码放到正确的意图位置

[GeekGao]

@kenvix 可读性的定义，不是你 COPY 代码的时候作用域好不好找。可写性指的是编写代码的容易程度。

具有良好可读性的语言可以带来的优势：

更容易理解和维护代码
减少错误的可能性
提高团队协作效率
降低学习曲线

所以，仅凭你的回复，我并认可你对 Python/YAML 可读性的解读（虽然我理解从排版错误的地方 COPY 代码会出错的这个问题）

[GeekGao]

@kenvix 而且，我刚开始写代码的时候，在 Linux 环境下使用 VIM ，Java 这种语言脱离 IDE 根本就无效率可言，更不要说什么可读性了。 况且啊，Python 出现的时间早于 Java 这套体系。

锁进这种设计也是有历史缘故的。90 年代初期，可没有啥好用的 IDE 吧。X11 逐步普及*nix 后才有人搞 GUI 类的编辑器啊。不能脱离历史讲优劣。从 Sun 发布的 Java Workshop 、Eclipse…… 到 Jetbrains 全家桶。这个对工具效率提升的能力跨度，不是隔夜就达成的。

[kenvix]

@GeekGao #49 确实，我是从 copy 的角度切入举例 yaml 可读性差的的问题，这个切入点可能是不合适的，切到 yaml 可写性极差的问题了。
但是这玩意可读性是真的差，没有高亮括号导致很难瞬间快速定位到当前所在的作用域的范围，必须额外费力观察缩进才能知道当前作用域是哪些
注释掉的 yaml 代码，可读性更是地狱了

[GeekGao]

@kenvix YAML 早期我也讨厌（更喜欢 JSON 这种通用配置，或者 INI 这种早期我学 Windows 开发的时候的概念） 我是玩了 k8s 后才逐步接受 YAML 的。

关于缩进问题，历史上有太多的争论了，我觉得个人偏好还是不一的，这个没啥科学说法，coding 时开心舒适就好。

[kenvix]

@GeekGao #52 K8S 的缩进嵌套深度姑且还在正常范围，主要是 CI/CD 的那个 yaml 真是写的高血压，不知道是哪个大聪明拍脑袋决定的🤣

[phx13ye]

@GeekGao "一个大类下面子类的数量，多到可以横跨好几个屏幕高度。"

openclash ，机场订阅和转换模板结合后最终生成的那个 yaml 配置

[seedhk]

突然想起有个国产框架叫做 Nutz ，他的配置文件是写在 js 里的，类似：
{
obj:{
xxx:xxx
}
}