使用json、yaml、toml作为配置文件，你知道他们的区别吗

前言

配置文件，不言而喻，主要是我们进行项目和工程配置的文件。

如果是站在前端角度说的话，我们最常接触的就是 json以及 js类型的文件，这种形式的配置写法对前端非常友好，因为都是我们熟悉的 JS 对象结构，如：

• package.json
• webpack.config.js
• babel.config.js
• vue.config.js

不过，随着技术的更新迭代，也涌现出一些新的配置文件格式，相比较而言，原有的文件格式好像也变得不是那么好用了。虽然在此之前，json+js用着也不错，不过，当新的工具出现后，尤其是在你深度体验与使用之后，可能会发现事情似乎有点那么不一样了，感觉新的玩意就是好啊😏，也便开始嫌弃之前的家伙了~

不过，我们要站在不同角度思考问题，从新工具诞生的角度看，其诞生必然有着一定的历史背景存在，如：

1.旧工具在某些场景表现吃力，需要更优的替代方案
2.旧的写法和模式在某些场景下有着明显的短板和缺陷，需要更进一步的完善方案

背景

最近在做开源项目的时候，在开发功能时，考虑到不同场景、不同用户的不同需求，在开始设计功能时就考虑到预留一定的可定制窗口方便用户进行定制化配置。当然，在功能不断开发进行时，以及后期的迭代拓展时，都会源源不断的诞生出各种小功能和定制需求，因此，对于拥有一个足够简单、易用、拓展的配置文件是相当有必要的。

它应该具备以下基本能力：

1.支持注释：对于配置文件来说，注释的重要性不必多说，它需要描述每个配置字段的作用
2.足够简单：语法足够简单，用法足够简单，上手足够简单；至少保证新人能很快上手使用
3.方便读写：对于用户来说，应该是可读性非常高的，符合人类语言习惯的，概览之后可以快速上手配置

在此之前的版本，我已经针对该想法做了初步的实施落地，从个人经验来说，我之前在搞 CI/CD 自动化部署相关的东西时，写过一些 github action（配置文件为yaml格式），因此，对于yaml语法算是有些了解。

从使用感受上来说，它语法更简洁、支持注释，所以，我果断选择了yaml作为我对于项目的配置文件格式。

不过，在这段时间的使用过程中，我也发现了yaml存在的一些问题，因此，最近我又重新思考了一下下这个问题：

1.是继续按照传统的js文件的对象写法呢？
2.还是继续使用yaml作为配置文件使用呢？
3.还是进一步研究一些其他类型的配置文件呢？
4.这些配置文件类型又有啥本质区别呢？

抱着学习的心理，咱不能在遇到问题的时候就选择逃避呀，那么本篇文章也算是对不同类型配置文件的一种研究和学习了。

简单介绍

JSON

JSON的定义一般是作为数据格式，它通常用于序列化、结构化数据并通过网络进行交换，通常发生在服务器与 Web 应用之间。不过也有很多工具将其作为配置文件使用。

JSON 其实完全可以当成是 JS 对象的形式进行理解、使用。

其实使用JSON作为配置文件也有其一定的优势：

1.语法非常简单，纯粹的键值对结构
2.很多编程语言的标准库都支持 JSON，比如：在JS当中你可以直接引入读取
3.现在几乎所有的工具都提供 JSON 支持，包括语法突出显示、自动格式化、验证工具等。
4.采用人类可读的轻量级文本，只需更少的编码，处理速度更快

但是，也因为其独特的定位，它天生就注定了并不适合作为配置文件使用，原因也很明显：

1.不支持注释：对于配置文件来说，注释的重要性不言而喻，但是JSON不支持添加注释（JSON 作为一种数据交换格式，也不需要注释😅）
2.语法过于严格：键和字符串必须使用""双引号（其实对于键来说，并不需要使用引号），结尾不允许有逗号（除了结尾都必须有逗号，哈哈~）
3.多余的最外层大括号：作为配置文件来说，最外层的大括号也显得有些多余（这也是其作为交换数据格式的特点，为了界定不同的对象）

虽然大家都很熟悉了，我们还是按流程看下基本用法，方便接下来做对比，如下：

{"name": "cat","desc": {"color": "orange","age": 1}
} 

可以看出JSON作为数据格式，还是比较合适且优秀的，但是作为配置文件来说，总觉得是力气使错了方向😄

YAML

YAML 是一种数据序列化语言，通常用于编写配置文件（它的流行和 k8s 脱不了关系😏~）。

语法规则：

• 大小写敏感
• 使用缩进表示层级关系
• 缩进时不允许使用Tab键，只允许使用空格。
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可