使用JSON作配置文件已經成了一種趨勢。
不要這樣做，一次也不要。因為這是一個非常糟糕的做法。
JSON的設計初衷不是用來幹這個的。JSON是一種“輕量級的數據交換格式”，它“易於人類讀寫”和“便於機器解析和生成”。
作為一種數據交換格式，JSON相當不錯。人們可以輕易閱讀和編寫它，機器也很容易解析（儘管存在問題）。在機器可讀和人類可讀性之間取得很好的平衡，相對於XML有了巨大改進，我認為XML對機器或人類可讀性都很差。
將它用於其它目的有點類似於說：“嘿，這個錘子釘釘子真好用！我喜歡它！為什麼不用它釘螺絲呢？”當然，這也是一種方法，但對於這項工作來說是使用了錯誤的工具。
缺點詳述
1、沒有註釋
這是迄今為止最大的問題：您無法在JSON中添加註釋。少數JSON解析器支持註釋，但大多數不支持，而且不符合標準，事實上，出於種種原因，JSON已經明確不支持註釋。
這會產生許多問題。
--沒有辦法記錄設置原因。
--沒有辦法添加助記符或警告。
--沒有辦法在配置文件中保存一個基本的變更日誌，記錄做了哪些更改（記錄這些更改可能是非常有用的）。
--更難調試，因為快速註釋掉一部分代碼是不可能的。
一種解決方法是使用新的鍵值對，例如：
但這真是太醜了。
有人說你可以使用操作日誌啊，但這是一個更糟糕的想法。看看下面使用bower文件包管理器的例子：
那麼，為了查找一些重要的信息，你是否會查閱全部操作記錄？
當然不是。
2、可讀性
這不是一般意義上的可讀性。對於數據交換格式是可讀的，但對配置文件不可讀。
可讀性很重要。
3、標準嚴格
JSON標準相當嚴格，這是它的優點，用簡潔和快速的解析器，不必處理不同的格式，但這也意味著編寫起來更加困難。
例如，對象或數組中的逗號是一個錯誤，並且已經多次困擾我。如果你的字符串中包含很多雙引號，那麼轉義所有的實例或者引號會非常麻煩。
4、缺乏可編程性
不總是這樣，但有時候就是這樣，特別是當使用JSON配置某段代碼時。
例如：
例如在MediaWiki的skin.json文件中，這是一個問題。如果我加載了某個插件而不想包括其中的CSS， 我們可以在PHP文件中解決它，但“解決”事情永遠不是最好的方法（記住，我們不能在JSON文件中添加註釋，告知人們我們正在解決問題！）
MediaWiki中的老辦法（聲明類變量）要好得多，而且功能更多。
替代方案
——JSON的創造者Douglas Crockford的“推薦方式”是“在將文件交給JSON解析器之前，通過JSMin管理它”。一些JSON解析器也明確支持註釋（但大多數不支持）。但預先處理配置文件是一件痛苦的事情。
——使用import, require, include或其它任何語言的代碼導入工具（甚至是eval）。這意味著配置文件必須是可信來源，而通常都是可信來源。
——ini文件;不是標準化的，但這通常不是問題，因為配置文件通常只能被一個程序讀取。
——TOML與ini文件非常相似，但這是標準化的。
——YAML有點不錯...我猜...但我不是很喜歡它，我專門寫過一篇文章：YAML可能並不是那麼好用（鏈接：http://arp242.net/weblog/yaml_probably_not_so_great_after_all.html）。
——雖然我不想推薦這個方法，但“自己製作”配置文件解析器非常簡單。在Python中：
真實例子
點名批評:-)
——MediaWiki的新擴展註冊系統（鏈接：https://www.mediawiki.org/wiki/Manual:Extension_registration）促使我寫這篇文章。
——npm的package.json（使用一個有點愚蠢的系統來添加註釋）。（鏈接：http://stackoverflow.com/a/14221781/660921）
——bower不支持註釋，這很白痴。（鏈接：https://github.com/bower/bower/issues/1059）
...還有很多很多例子......
建議:
JSON配置文件格式，參考鏈接http://octodecillion.com/blog/json-data-file-format/
反饋
您可以給我發郵件[email protected]，或者創建一個GitHub issue 以獲得反饋。
英文原文：https://arp242.net/weblog/json_as_configuration_files-_please_dont
譯者：錢利鵬
閱讀更多 Python部落 的文章
