缺乏一個標準 最初，Markdown是由John Gruber寫的initial implementation來定義，但並未明確規定行爲規範。 隨着Markdown越來越流行，越來越多的站點開始支持Markdown的實現，這些站點是用其它語言寫成的，因此產生了更多的Markdown實現。所有這些實現有輕微差別，但都達不到令人接受的程度。 比如有些實現要求開頭有一個空格，但另外的一些不做要求： 
風格 Markdown缺乏採用的主要原因是這些年來其一直在變化。起初，Markdown功能很有限，每當有流行的工具在Markdown上實現的時候，都會有一個特定的風格。聽起來不錯 ，是吧？問題是每一個工具都形成了不同的風格，甚至連實現相似任務的工具都有不同的語法。 舉個例子，在Markdown Extra 中代碼塊是下面這種樣式： 
缺乏擴展 其它的標記語言，可以對其進行擴展以提供需要的功能。它們在語法上有增添新功能同時又不會違反初始規範的機制。 比如reStructuredText，具有內嵌和塊級別的標記： 
缺乏語義化 儘管很多人添加了很多擴展，但都不夠語義化。這意味着不能寫Class或Warning，只能寫文本。因此很多人直接將HTML嵌入到Markdown中： 
- 現在Markdown依賴於顯示中的特定CSS類，這意味着編寫者必須考慮如何設計頁面。
- 內容不可再移植到其他輸出格式（PDF等）。
- 轉換到其他標記工具和頁面設計變得更加困難。
注意： 在我的博文Semantic Meaning in Authoring Documentation中有關於語義化更詳細的介紹。
鎖定和缺乏可移植性 風格的多種多樣及缺乏語義化導致鎖定。一旦創建了大的Markdown文檔集，就很難將它們遷移到另一個工具上，即使該工具宣稱支持Markdown！自定義的HTML類和奇怪風格的擴展組成的文檔集，除了在當前的工具和設計外，在其它地方都行不通。 同時也無法輕易將Markdown遷移到其他標記語言（Asciidoc或RST），因爲Pandoc和其他轉換工具不支持您風格的擴展。 很多人選擇Markdown是因爲他們認爲他們可以在稍後遷移到其他工具或其它標記語言。 Markdown絕對是最低的共同標準，除非文檔集足夠小，否則你所需要的東西都不在基本語法中。 任何有意義的文檔都需要擴展，而一旦使用Markdown各種各樣風格的擴展，你將失去所有可移植性的優勢。
結論 我認爲CommonMark是向前邁出的一大步，如果它被更廣泛地使用，並且增加對擴展的支持，我會全心全意地推薦它作爲解決這個問題的方法。我不能擁護Markdown目前的生態系統，並且我認爲它很大程度上阻止了人們使文檔變得更好。 我希望我們可以開始推進更加標準化的語言集合，包括CommonMark，reStructuredText和Asciidoc，在我們使用的工具套件中全面支持他們。目前，Sphinx和Asciidoctor是很好的替代品。它們語音內部內置了更多的擴展，並且含有用於構建當今文檔更完整的工具。 Markdown更像是一個概念，而不是實現。 它通常意味着“在看起來與Markdown類似的語言上的一組互不兼容的擴展”。 當創建大的文檔集時，它顯然不是正確的工具。 披露：我從事的一款產品，Read the Docs，是基於Sphinx的，所以我的觀點可能有偏頗。
英文原文：http://ericholscher.com/blog/2016/mar/15/dont-use-markdown-for-technical-docs/ 譯者：Chris