这是一个创建于 102 天前的主题，其中的信息可能已经有所发展或是发生改变。
很多服务需要一个配置文件，有一些常见格式：
- xml: java maven ，这个是我觉得最鬼畜的，可读性极差
- json: 很多前端相关的服务的配置
- yaml: k8s 喜欢用这个
- toml: 感觉比较小众，我用过的服务中，只有 cloudflare 用这个
- 纯文本: 比如 CMakeLists.txt ，感觉年代久远的服务会更喜欢直接用文本
一个服务用什么格式的配置文件，这个有什么考量吗？用什么比较好？
55 条回复 • 2024-09-18 09:51:24 +08:00
 |
1
summerwar 102 天前
用啥都可以，你最熟悉啥用啥就行了，都是读取文件，然后把配置拉到代码里
|
 |
2
dreamk 102 天前  1
toml 是目前最先进的配置文件格式
|
 |
3
chendy 102 天前
熟悉啥用啥，不知道用啥就 json
反正逻辑都是一样的，读文件，反序列化，用 |
 |
4
0o0O0o0O0o 102 天前
其实我觉得你可以都用，我就很喜欢同时支持命令行参数, env, yaml 和 json 的项目
|
 |
6
dcsuibian 102 天前
选择 yaml ，选择成功
|
 |
7
kirory 102 天前
还有 .ini, .env
|
 |
8
Hopetree 102 天前
yaml 是目前最好的配置格式，就相当于 markdown 格式一样的存在
|
 |
9
aloxaf 102 天前 1
简单的用 toml ，复杂的用 yaml
json 、xml 这种不是给人读的 CMakeLists.txt 这种属于 DSL 了 |
 |
10
cwcc 102 天前
如果只是读取的话，我个人 yaml 、json 是最推荐的。json 的好处就是兼容性极广，缺点就是不能注释且比较冗余。yaml 的好处就是可读性强且兼容 json ，缺点就是写的话比较混乱。toml 个人觉得有一定门槛但未来可期，ini 太过简单，xml 适合同时读写的复杂结构。
|
 |
11
IvanLi127 102 天前
我选 toml ，如果没复杂的嵌套结构，还是环境变量和 .env 文件比较舒服。如果需要被程序修改的需求，我选 yaml 或 json 。
|
 |
12
flyqie 102 天前 via Android
我个人环境变量、.env 、.ini 写的都比较多，再加上不喜欢那种缩进，一直很偏好 toml
|
 |
13
Trim21 102 天前
yaml 或者 toml
|
 |
14
pb7412221 102 天前
json 是最简单最容易的 唯一的缺点不能写注释 在 json5 中也解决的
|
 |
16
Philippa 102 天前
支持楼上，选择 json 。因为 json 简单易懂，所有人都有相关基础，是最好用的。
toml 有点冷门，很多人不熟悉怎么用。单是先进是不够的。 yaml 就算了吧，你看看 k8s 的那堆文件还有 nindent ，缩进错一丢丢都不行，偶尔字符串偶尔数字，array 表达让人迷惑。 |
 |
17
agagega 102 天前 via iPhone
扩展性：XML>YAML>JSON>TOML
安全性：TOML>YAML>JSON>XML 人类读写：YAML>TOML>JSON>XML 苹果有个叫 pkl 的开源项目，大致相当于给不同的配置文件格式准备的配置文件，你可能会感兴趣 至于 CMakeLists.txt ，即使再怎么吹 modern ，本质上还是一个奇怪的命令式语言，用它还不如用 Lua 或者 Ruby 正经搞个 DSL ，我宁愿写 XML 也不想写它 |
 |
18
kenvix 102 天前 via Android 3
我不知道为什么这么多人喜欢 yaml 。这玩意简直就是一坨屎，我永远不知道当前缩进对的是哪里，这个缩进有没有问题。IDE 也猜不到想表达这块代码的意图位置是哪里。
但凡写过几百行的 yaml 应该和我有同感 |
|
19
kenvix 102 天前 via Android
如果是几百行甚至上千行以上，有各种复杂逻辑结构的，你就应该用 XML 。明确的作用域和结尾复述对人类心智真的很友好。
如果比较简单，那就 TOML 。 如果极其简单，那就.env yaml 适合 100 行以下规模，超过这个我看见就恶心 另外 hocon 也可以考虑下 |
 |
20
GeekGao 102 天前
参考：
 |
 |
21
daimaosix 102 天前 via Android
我比较喜欢 yaml
|
 |
22
baobao1270 102 天前
选你用的语言
如果用的 JavaScript ，那就用 js 文件做配置 如果用的 Python ，那么就用 py 文件作为配置 直接 code as configuration |
 |
25
lrh3321 102 天前
手写 toml 不容易犯错误。yaml 在编辑器里写也还好。
|
 |
26
fenglala 102 天前 via iPhone 1
推荐 json5 ，解决了 json 好多弊端，注释什么的都没问题。量大的话不推荐 yaml ，在公司见了上万行的 yaml 格式 git 仓库配置文件，几乎完全不可读，加一行加到哪都很难找。
|
 |
27
Pony69 102 天前
简单 toml ，复杂 yaml
|
 |
28
henix 102 天前
最简单的直接用环境变量
没有复杂嵌套的用 ini 复杂的用 json5 或 json 不推荐 yaml ，这玩意一旦规模上去之后，可读性大幅下降。而且 spec 相当复杂，不同语言实现出来的 yaml parser 可能有功能上的差异，导致同一个配置文件，无法在不同语言之间迁移 |
 |
29
zhuangzhuang1988 101 天前
用 Python ，lua 当配置文件啊。
|
 |
30
lisxour 101 天前
ini toml yaml .env 这几个都是对人类比较友好的，好改很多，结构也比较扁平，json 、xml ，可以存，但是如果经常需要人工修改的场景不建议用
|
 |
32
abcbuzhiming 101 天前
@kenvix 因为 k8s 用 yaml 这东西，而 k8s 用这东西的核心原因是，k8s 工程师写配置文件的量非常大，几万行的配置文件和家常便饭一样。典型的写多读少。对于他们来说，节省几个字符串带来的收益海了去了，所以 yaml 才是这个样子。
但是对但部分其它人来讲，配置文件永远是读多写少。yaml 这种读起来一泡污的语法就一点都不友好了 |
|
33
abcbuzhiming 101 天前
@GeekGao 这上面写错了，yaml 根本就不易读，人眼的生物特性，更适合横向扫描，而不是纵向位移。这就决定来了 yaml 读起来一点都不友好。而且 yaml 之所以设计成这样就是因为 k8s 的配置代码量非常大，所以少写一个 key 的收益就特别大。yaml 是少见的专门针对写多读少环境的配置语法
|
|
35
GeekGao 101 天前
@abcbuzhiming 我写了很多年 Python ，我认为 YAML 易读。 这个理由很简单，就像你 “这上面写错了，yaml 根本就不易读” 这句话讲的很轻松那样。
|
 |
36
wheat0r 101 天前
如果配置不是太复杂，toml 挺好用，而且 toml 并不算小众，传统软件的配置文件都是这个风格的，只是名字不叫 toml 。
yaml 的易读程度和屏幕高度正相关，在 16:9 屏幕上就是屎，9:16 屏幕上就好不少。 |
|
37
abcbuzhiming 101 天前
@GeekGao 我给了理由，不是随便轻松的讲话，人眼的特性就更适合横向扫描。况且你是不是觉得 python 和 yaml 都是有缩进，就觉得这两个玩意一样？你见过 yaml 子项的数量多到可以横跨整个屏幕高度的情况没？
|
|
38
GeekGao 101 天前
@abcbuzhiming 我还没有遇到感觉很复杂的 case ，我遇到的最复杂的例子是 k8s depolyment 的配置，几百行。
问题是我不需要修改所有配置，所以也感受不到你所述 “横向扫描” 困难的问题。 |
|
39
abcbuzhiming 101 天前
@GeekGao 我前面说了，yaml 这个东西之所以被 k8s 广泛采用，就是因为 k8s 的工程师动不动就要些几万行的配置文件。在这种数量级下，同样的配置项，少写一个 key 就成为了收益性很高的一件事。所以 k8s 才选了这个格式作为自己的配置文件。
你自己只需要写几百行 k8s 配置，那你一个大类下面有几个子类不得了了，那自然是体会不到这玩意难读的。实际上国外社区已经不止一次抨击过 yaml 作为 k8s 的配置文件“难以阅读”了。就在于我说的，它们说的这种“难读”的 yaml ，一个大类下面子类的数量，多到可以横跨好几个屏幕高度。看着看着眼睛就花了 |
|
40
GeekGao 101 天前
@abcbuzhiming "一个大类下面子类的数量，多到可以横跨好几个屏幕高度。" 有在线的例子可以分享吗 ？ 我去感受一下
|
|
41
abcbuzhiming 101 天前
@GeekGao 我手上并没有，但是老外的社区说过不止一次这个问题，想来不是空穴来风
|
 |
42
iorilu 101 天前
简单的就是.env, 其他都用 toml
|
 |
45
chinni 101 天前
adguard 的 yaml 配置 我后台里配置了几千条记录 然后打开配置文件 基本没法看
|
 |
46
X_Del 101 天前 1
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 ） |
 |
47
ns09005264 100 天前
bspwm 的配置文件是 shell 脚本，bspwm 本身是 daemon 类型的软件，通过客户端 bspc 与 bspwm 通信实时变更相应的配置。所以可以把一堆 bspc 的操作命令放到 shell 脚本里执行，就相当于配置了。
类似的还有: neovim 是用 lua 语言作为配置 nixos 是用 nix 语言作为配置 |
|
48
kenvix 100 天前
@GeekGao #35 我写了 8 年 java （ xml 宇宙）、7 年 python （缩进宇宙）、4 年 kotlin （ dsl 宇宙），我认为 yaml 和 python 可读性都是一坨屎。作用域对人类不明确，特别是从外面抄代码时，IDE 根本不能把代码放到正确的意图位置
|
|
49
GeekGao 100 天前
@kenvix 可读性的定义，不是你 COPY 代码的时候作用域好不好找。可写性指的是编写代码的容易程度。
具有良好可读性的语言可以带来的优势： 更容易理解和维护代码 减少错误的可能性 提高团队协作效率 降低学习曲线 所以，仅凭你的回复，我并认可你对 Python/YAML 可读性的解读（虽然我理解从排版错误的地方 COPY 代码会出错的这个问题） |
|
50
GeekGao 100 天前
@kenvix 而且，我刚开始写代码的时候，在 Linux 环境下使用 VIM ，Java 这种语言脱离 IDE 根本就无效率可言，更不要说什么可读性了。 况且啊，Python 出现的时间早于 Java 这套体系。
锁进这种设计也是有历史缘故的。90 年代初期，可没有啥好用的 IDE 吧。X11 逐步普及*nix 后才有人搞 GUI 类的编辑器啊。不能脱离历史讲优劣。从 Sun 发布的 Java Workshop 、Eclipse…… 到 Jetbrains 全家桶。这个对工具效率提升的能力跨度，不是隔夜就达成的。 |
|
51
kenvix 100 天前
@GeekGao #49 确实，我是从 copy 的角度切入举例 yaml 可读性差的的问题，这个切入点可能是不合适的，切到 yaml 可写性极差的问题了。
但是这玩意可读性是真的差，没有高亮括号导致很难瞬间快速定位到当前所在的作用域的范围，必须额外费力观察缩进才能知道当前作用域是哪些 注释掉的 yaml 代码，可读性更是地狱了 |
|
52
GeekGao 100 天前
@kenvix YAML 早期我也讨厌（更喜欢 JSON 这种通用配置，或者 INI 这种早期我学 Windows 开发的时候的概念） 我是玩了 k8s 后才逐步接受 YAML 的。
关于缩进问题，历史上有太多的争论了，我觉得个人偏好还是不一的，这个没啥科学说法，coding 时开心舒适就好。 |
 |
55
seedhk 99 天前
突然想起有个国产框架叫做 Nutz ，他的配置文件是写在 js 里的，类似：
{ obj:{ xxx:xxx } } |
Select Language