第4章 方言与规范

第4章 方言与规范

章节摘要：为什么同一个文件在 GitHub 上表格好好的，换到某个笔记软件就成了一堆竖线？因为 2004 年的原版 Markdown 早已分化成一片方言群。本章讲清三件事：CommonMark 如何试图统一语法、GFM 在其上加了什么、以及各家扩展方言的取舍——读完你写的文档能预判"换平台会不会翻车"。

学习目标

阅读完本章，你应当能够：

1. 说清原版、CommonMark、GFM 三者的关系与时间线。
2. 列出 GFM 相对 CommonMark 的主要扩展：表格、删除线、任务列表、自动链接、代码围栏。
3. 面对一个发布平台，快速判断它支持哪一层语法。
4. 为多平台发布的文档制定"保守语法子集"策略。

核心概念速览

方言不可怕，可怕的是不知道自己正在用哪门方言。

子章节导航

4.1 CommonMark：语法的共同底线

规范是怎么来的，它精确定义了什么、又刻意不管什么。

4.2 GFM：事实上的互联网标准

代码托管平台打磨出的扩展集，你我每天在用的语法大多属于它。

4.3 方言盘点：Multimarkdown、Pandoc 与平台扩展

脚注、数学、图表各有出处，多平台发布怎么选。

子章节之间的逻辑关系

三节是一条演进时间线，也是一次"支持范围"的逐层扩张：

CommonMark（基础底座，纪律最严）
   └── + GFM 扩展（表格/任务列表/删除线/自动链接）→ 覆盖日常九成需求
          └── + 各家方言扩展（脚注/数学/图表/导出）→ 表达力天花板
​

每往上一层，表达力更强、可移植性更弱。写作时的位置由发布平台决定。

前置知识与后续延伸

• 前置：第 1、2 章的语法细节——你会在这里找到它们各自的"户口"。
• 为后续铺垫：第 5 章的渲染器选型本质上就是"选一门方言"；第 6 章的团队书写规范里"语法子集约定"直接依赖本章结论。

团队方言公约：一页纸的版本

本章知识在团队里落地的形态是一页纸公约，比口头共识可靠得多。公约只需要四条。第一条，声明本团队的主力方言（多数团队写 GFM）及其启用范围，从此"能不能用表格"不再是争论。第二条，规定跨平台交付物的语法子集——核心正文限基础语法加 GFM，特化语法白名单列出（比如仅允许脚注与折叠）。第三条，约定换行写法统一为"空行分段、段内不依赖单回车"，这是方言差异里最隐蔽也最高频的错乱源。第四条，指派方言问题的裁定入口——遇到"怪渲染"先查 4.1 的判定流程与团队登记表，仍无结论时由谁拍板。这页公约应随工具链演进每半年复审一次；它不能消灭方言，但能把方言带来的摩擦从每次发布降到每次复审。

本章各节的知识还可以压缩成一张随身速查：写互联网内容按 GFM 赌、要转换按 Pandoc 开关、进组件工程用 MDX、个人笔记选 Obsidian 方言；拿不准的语法查 CommonMark 测试集；跨平台交付按"核心 GFM、特化白名单、平台补丁"三层拆。这张表配上 4.3 的迁移走查流程，就是普通作者需要的全部方言装备。

本章的收尾提醒：方言知识半年就会局部过时（平台改版、规范演进是常态），但判定流程与三层拆分的方法论长期稳定。记住方法而非背记清单，遇到新平台新怪象时按流程走一遍，答案总能定位——这是把"学过的知识"变成"带得走的能力"的唯一路径。