Markdown 引用块：引用、多段落与列表

Markdown 引用块以 > 加一个空格开头。在每一行被引用内容的开头都加上这个标记，可以让源码更易阅读和编辑。

> 修订后的安装指南已准备好，可以开始审阅。

结果是一个引用段落，而不是代码块。它的边框、缩进和颜色取决于页面或文档主题。引用中的文本仍然是普通 Markdown，因此可以包含强调、链接、列表和其他文档结构。

使用 Markdown 查看器试验这些示例；需要一份可编辑的审阅副本时，再通过 Markdown 转 Word 转换器导出文档。

用多行源码引用一个段落

对于较长的引文，请重复使用标记：

> 修订后的安装指南已准备好，可以开始审阅。
> 批准发布之前，请检查前置条件。

在本站预览中，这两行源码会组成一个段落。源码中的换行不一定会强制在显示时换行。如果文字必须分成两行，请添加明确的换行标记：

> 文档审阅\
> 分配给发布负责人

反斜杠放在换行符之前；下一行仍以引用标记开头。硬换行和段落分隔的区别，请参阅 Markdown 换行指南。

在段落之间原本为空的那一行上放一个引用标记：

> 第一版草稿介绍安装流程。
>
> 第二版草稿补充故障排查步骤和示例。

这会生成一个包含两个段落的引用块。在分隔行保留 >，可以清楚地表明这些内容属于同一组，尤其方便其他人日后编辑。

要继续写自己的正文，请留一个空行，然后在不加引用标记的情况下继续：

> 审阅意见要求缩短安装章节。

我们已将详细的配置说明移到附录。

不要在没有添加空行的情况下，直接删掉续行前的 >。某些 Markdown 解析器会把它视为引用段落的惰性延续。CommonMark 引用块规范说明了这种行为。明确的标记和清晰的空行更有利于协作者维护文档。

引用块内容可以使用常规行内格式：

> **审阅意见：** 迁移步骤需要一个可运行的示例。
> 请参阅[发布检查清单](https://example.com/checklist)。
>
> 来自 2026 年 9 月文档审阅的反馈。

Markdown 不会为最后一行赋予特殊的引用来源角色。它只是引用块中的普通段落内容。需要时请注明来源、作者和链接；转载他人的文字之前，请确认使用权限。

引用块也不会自动添加字面上的引号。如果最终文档需要引号，请自行输入。如果只是在自己的句子中嵌入一小段引文，直接使用普通引号可能就足够了，无需创建独立的引用块。

对于外层引文中的引用内容，再增加一级 >：

> 审阅者总结了之前的要求：
>
> > 添加一个完整的配置文件示例。
>
> 更新后的草稿现在已包含该示例。

报告中的嵌套层级应尽量浅。过深的引用嵌套会压缩文字可用宽度，使 PDF 和 Word 的版面更难阅读。

引用块内部的列表需要在每一行都保留标记：

> 审阅指出了两项修改：
>
> - 说明所需权限。
> - 添加故障排查章节。

反过来，如果要在列表中加入引用，请将引用缩进到列表项正文下方：

- 文档反馈

  > 发布之前添加故障排查章节。
- 发布检查清单

如果引用显示在列表项之外，请对照 Markdown 缩进指南中的示例检查缩进。

GitHub 支持基于引用语法的特殊提示框，包括以下形式：

> [!NOTE]
> 修改配置之前，请先备份。

GitHub 在提示框参考文档中列出了支持的类型。提示框的颜色和图标属于平台功能，并不是所有 Markdown 引用都具有的特性。

本站渲染器不会添加 GitHub 的提示框样式。这个示例仍会显示为引用块，并保留可见的 [!NOTE] 标签。对于需要在不同目标平台上都清晰易读的文档，请使用明确的加粗标签：

> **注意：** 修改配置之前，请先备份。

这样即使没有特殊的提示框扩展，也能理解内容的含义。同样的方式也适用于警告、审阅结论或编辑备注。

如果 > 原样显示，请检查示例是否位于反引号、围栏代码块或缩进代码块中。这些环境本来就用于展示源码。在标记前加上反斜杠也会将其转义。

如果过多文本被纳入引用，请在应该恢复到引用块之外的段落前加一个空行。如果嵌套内容难以理解，请减少嵌套层级，并把来源说明写成普通段落。

最后，打开导出的 DOCX，检查长引文以及引用块中的列表。浏览器中的左侧边框可能与 Word 文档的段落样式不同。当需要区分源码格式问题和导出样式问题时，可以使用 Markdown 转 HTML 工具检查中间结构。