markdown术语解释

判断 Markdown 文档是否规范，重点看两点：是否清晰区分块级结构与行内修饰，以及是否明确目标渲染环境。以下术语按结构、规范、扩展、转义、引用和差异排列，适合写作、审校与工具配置时对照。

块级元素与行内元素

块级元素定义段落、标题、列表、引用、代码块等独立内容块；行内元素在块内部修饰文字，如强调、链接、行内代码。使用判断标准是：块级元素前后应空行，行内元素不能跨块。一个常见错误是连续空格或 Tab 缩进，CommonMark 会把四个空格缩进解释为代码块，而不是段落缩进。适用场景：在编辑长文档时，先确保每一级标题、列表和段落的空行关系正确，再处理行内强调，能减少解析错乱。

CommonMark 与 GFM

CommonMark 是力求统一的 Markdown 规范，定义标准语法和解析规则；GFM（GitHub Flavored Markdown）是 GitHub 在 CommonMark 基础上扩展的方言，增加表格、任务列表、删除线和自动链接等。判断标准：需要跨平台、跨工具一致呈现时优先用 CommonMark；面向 GitHub、GitLab 等平台发布时可以使用 GFM 扩展。选择步骤：先查看目标平台文档，确认它支持哪些扩展，再决定是否使用表格和任务列表。注意，GFM 并不代表所有 Markdown 工具通用，其他解析器可能不识别这些扩展。

解析器与渲染器

解析器将 Markdown 文本转换为结构化数据或 HTML，渲染器负责最终显示。不同解析器对空行、缩进、列表中断等细节处理存在差异，这是 Markdown 排版不一致的主要原因。可执行的做法是：发布前固定一个目标解析器（如 CommonMark.js、markdown-it、Pandoc），并用该解析器预览或转换一次。不要只依赖编辑器实时预览，因为编辑器内置解析器可能与最终环境不同。适用场景：团队协作或自动化发布时，把解析器版本写入工程配置，可减少“本地正常、线上错乱”的问题。

转义与代码标记

需要显示 Markdown 特殊符号本身时，使用反斜杠转义，例如 `\` 显示为星号。行内代码使用反引号包裹，代码块使用三个反引号并标注语言。判断标准：凡是不希望被解释为格式的内容，都要放进代码标记或逐个转义。操作步骤：先定位会触发格式的字符，如 ``、`_`、`#`、`[`、`]`、`` ` ``，再决定转义还是使用代码标记。注意，反引号内部的内容不会被 Markdown 解析，适合命令、路径、配置项和代码片段。

链接、引用与图片

链接行内写法为 `[文字](地址 "标题")`，引用式写法分两部分：正文中的 `[文字][id]` 和文末的 `[id]: 地址 "标题"`。图片语法为 ``，替代文字应描述图片内容，用于无障碍访问和加载失败时的提示。判断标准：所有链接地址应可点击验证，图片需检查替代文字是否准确。注意，标题属性可省略；装饰性图片可使用空替代文字 `![]()`，但内容图片应保留清晰描述。

表格与任务列表

表格属于 GFM 扩展，列用 `|` 分隔，第二行用 `---`、`:---`、`:---:` 控制左对齐、右对齐和居中；单元格内出现 `|` 需要写成 `\|`。任务列表使用 `- [ ]` 和 `- [x]` 表示待办与完成，同样属于 GFM 扩展。适用场景：表格适合参数对比、版本差异说明；任务列表适合进度跟踪和发布清单。注意事项：并非所有 Markdown 平台都支持这两类扩展，发布前需确认目标环境支持，否则会显示为普通文本或错乱。 掌握以上术语后，写作顺序可以固定为：先按块级元素搭建结构，再用行内元素修饰文字；遇到平台差异时以 CommonMark 为基线，按需使用 GFM 扩展。最后在目标解析器中预览，验证链接、图片、代码块和表格，能显著降低发布后的格式异常。