GitHub 使用的是 “ GitHub Flavored Markdown ” ，简称GFM，有site-in issues,comments,pull requests等功能，它与标准的Markdown有一些区别，并增加了些新的扩展功能
Github上的一篇高star语法讲解：README文件语法解读，即Github Flavored Markdown语法介绍。但都是讲一些很基础的。像实际问题中遇到的四重列表嵌套外带多层中插入注释，这里面并没有讲到。
| Problem | Solution | |
|---|---|---|
| 0 | 我把大段文段复制到 MarkdownEditor.io 上进行重新编辑，再贴回 github修改框 后，发现格式依然是乱的，只不过由一种乱法变成了另一种乱法。 | 上网去查，发现GFM是一种独立于Markdown的语法。在一些语法的书写上，比如列表多重嵌套，并在其中多层插入注释字段时，语法与普通的 Markdown 语法还是有很大的差别的。之前学习Markdown的时候，虽然知道Markdown有很多变种语法，但是写的都只是一些简单的嵌套，并没有涉及三四重以上的嵌套，也没有在嵌套中插入注释，所以一直没觉得GFM和Mrakdown有什么区别。直到碰上了具体情况需要这种的复杂书写时，才暴露出了这个问题。 |
| 1 | 用GFM书写简单语法时，用两个空格键就能代替Tab。空格键和Tab键常常可以多打也没关系。于是我在多重嵌套的时候依然这么干。。然后就悲剧了。。T T | 在书写GFM时想要不犯错，缩进必须要严格采用Tab键（Tab键会等于超级多个空格，远不止四个）。Tab键既不可以多打也不可以少打。 |
| 2 | 列表多重嵌套时，对其中某一项插入注释 | 如果注释句要与被注释的句项都是４个#字体大小的（注意：正常大小字体也会被当成前面加了4个#来识别），为了让转换器识别出这是两句从属关系的语句，则插入之前，该注释句要与被注释的句项间隔至少一行；如果注释句要与被注释的句项字体大小不一样，则可以不用空行。但是不论是哪种情况，该注释句都必须要比被注释的句项恰好多空一个Tab（只管敲Tab就好了，就算觉得每个Tab离得再宽，编辑器也会自动帮你识别清楚的；但是对列表树根进行注释时，该注释句 却不能 比被注释的句项多空一个Tab。。。没搞懂为什么会这样 T T ） |
| 3 | 某些时候会把语法符号也跟着显示出来，或者一些语法转换成h5时错乱 | 可能是输入时，输入状态还是处于“中文”状态下。像空格，在“中文”状态下打出的一个空格距离和“英文”状态下打出的一个空格距离是不一样的。 |
| 4 | 因为Markdown系列的语法最后要被转换成h5，所有可以在Markdown系列(包括GFM)文本中插入h5字段，以作为Markdown系列语法的补充，来显示出更多的效果。然而当我想在GFM写的表格中的某个空里，插入h5的代码写的列表时，发现怎么也写不出这个效果。 | h5代码 与 GFM代码 至少间隔 一行。也就是说，Markdown系列文本的原语法字段和插入的h5字段是分开来识别的，其中前者会被转换。因而h5字段只能在全局文本的基础上插入，并不可以在原语法字段的代码中强行插入。 |
| 5 | 写语法时，经常会牵一发而动全身，语法错误累积多了之后，会给修改造成很大麻烦。因为任何一种显示出来的错误，都可能是多个语法错误的综合作用结果。 | 规范书写很重要！语法正确要从娃娃抓起！！ |
| 6 | 有时候在修改代码时，改了一个地方好像把前面字段的显示改过来了，改到后面又发现前面字段的显示重新乱了。或者是感觉后面字段的语法完全没问题，但是就是显示出来不对（比如 #### 会一直被直接显示出来，或者三级列表项会一直被显示为二级列表项） | 还是因为语法错误累积得太多，牵一发而动全身。还是那句，规范书写很重要！ |
| 7 | 连续７个 # 后，无法转换成更小号的字体 | 标题字体 相当于前面加 2 个 #；正常字体 相当于前面加 4 个 #；灰色注释小字体 相当于前面加６个 #；但是前面加7个以上(含7个) # 就转换不了了。 |
| 8 | 输入时，发现刚刚从句首输入的一个单字符，闪了一下又消失了 | 把前一个句法的末位字符改成以 '英文输入状态' 输入 |
