这篇文章主要讲了JSON作为配置文件的缺点：
我最近目睹了使用JSON作为配置文件的趋势。我认为这不是一个好做法。
这不是JSON的设计目标，也不是它擅长的东西。
JSON旨在成为一种“轻量级数据交换格式”，并声称它“易于人们读写”和“易于机器解析和生成”。
作为数据交换格式，JSON非常好。
人们可以相对容易地读取和写入它，并且对于机器来说解析也很容易（尽管存在问题）。
这是机器可读和人类可读之间的良好折衷，对于许多用例来说，它是对XML的一个很好的改进。
将它用于其他目的有点类似于说“嘿，这把锤子非常适合驾驶钉子！我喜欢它！
为什么不用它来敲击这个螺丝！“当然，它有点工作，但这是工作的错误工具。
到目前为止，最大的问题是你无法添加评论。偶尔的JSON解析器支持它，但大多数不支持它，它不在标准中。
有充分理由明确从JSON中删除了评论支持。
您想要添加注释的原因有很多：记录为什么配置中为它们设置值，添加助记符或描述警告，警告过去的配置错误，在文件本身保留基本的ChangeLog，或者只是注释掉一个部分/
Debug时的值。
一个建议的解决方法是使用一个新密钥（例如{“__ comment”：“a comment”，“actual_data”：“......”}，但这让我非常难看。
其他人已经指出你可以使用提交日志，但谁会仔细阅读提交历史记录，那里隐藏着一些重要的消息？
一些JSON方言 - 例如JSON5，Hjson和HOCON - 添加了对注释的支持，一些JSON解析器也是如此。
这很好，我鼓励你使用它，但这不再是JSON而是JSON方言。
这篇文章是关于JSON，而不是JSON方言。
我还发现JSON的用户界面对于手动编辑来说相当不理想：你需要用尾随逗号来搞定，引用的语义很烦人，而且它缺乏使用多行字符串的能力。
这些属性适用于JSON的预期用途，但不太适合编辑配置文件。它可行吗？当然。好玩吗？不。我也发现它不是特别易读，因为它有过多的引用和其他语法噪音，我承认这是一个品味问题。
JSON是一种声明性配置语言。声明性配置（DC）适用于某些问题，但对其他问题则不太好。特别是，使用DC来控制逻辑通常不是一个好做法。促使我写这篇文章的是MediaWiki的新扩展系统。
旧系统使用一个简单的PHP文件来挂接核心MediaWiki代码，加载所需的依赖项等。这在新系统中被替换为JSON文件。丢失的是能够巧妙地解决与其他插件兼容或其他逻辑的问题。
它实现起来要复杂得多，以前只需要（'plugin / foo / plugin.php'）;现在它需要解析一个JSON文件并对其内容做一些事情。这要复杂得多，因此难以调试。
虽然使用JSON文件获取基本元数据是有意义的（更容易在网站上解析和显示），但使用它来描述代码的工作方式对我来说是滥用DC。毕竟，这就是代码的用途。
很多人都问我有关使用什么的建议。这不是一个容易回答的问题，因为它取决于您的用例，编程语言，库环境和社交因素。除了“最简单的满足您的所有要求”之外，没有单一的“正确答案”。我实际上写了一篇关于它的文章。
一个很好的选择可能只是使用命令行标志。有一些JSON方言专为人类编辑而设计：JSON5，Hjson和HOCON。所有这些看起来都是普通JSON的合理步骤，尽管我自己没有使用过它们。
特别是JSON5似乎是一个不错的选择，因为它对JSON的改动最少。我不愿意提出其他选择，因为我没有对所有格式（YAML除外）进行深入评估;只是看一眼规范可能并不明显潜在的缺点（YAML就是一个很好的例子，有很多微妙的行为）。
我没有时间 - 或者有兴趣 - 对所有替代方案进行全面深入的审查。
原文链接：https://arp242.net/json-config.html
作者：Martin Tournoij
译者：lee
