markdown排版语法

判断一份 Markdown 文档排版是否合格，通常看三个条件：渲染后目录层级连续、列表与代码块缩进一致、平台特有语法不干扰阅读。排版的目标不是装饰，而是让读者能快速扫读，让渲染器稳定输出。 ## 标题与段落 标题用于划分文档骨架，不用于放大字号。二级标题是主要分节，三级及以下逐级展开；不要从二级直接跳到四级。先列二级标题形成大纲，再在每节内填段落。普通段落之间空一行，不要用连续空格或 Tab 模拟缩进。需要强制换行时，可在行尾加两个空格或 `
`，但更推荐另起段落。 适用场景：README、博客、操作手册的大纲。判断标准：渲染后目录没有断层，同级标题含义并列。注意：不要把整行文字都设为标题，也不要只为一个词加 `#`。 ## 强调与行内代码 粗体用于关键结论或操作结果，斜体用于术语、书名或轻微区分。一段内强调不超过两到三处，否则会失去重点。行内代码用反引号包裹命令、参数、文件名、路径，例如 `npm install`、`/etc/hosts`。 适用场景：API 文档、故障排查步骤、命令说明。判断标准：去掉强调后句子仍然完整；行内代码可被复制而不含多余空格。注意：不要在代码片段内再嵌套粗体或斜体，也不要整句加粗。 ## 列表与任务列表 无序列表统一用 `-`，有序列表用 `1.`、`2.`。嵌套列表缩进二到四个空格，并且全篇保持一致。列表前后留空行，避免与相邻段落粘连。任务列表写作 `- [ ] 待办` 或 `- [x] 完成`，适合检查清单，但并非所有平台支持，需要确认目标渲染器。 适用场景：操作步骤、验收条件、发布清单。判断标准：同一层级符号一致，缩进对齐，渲染后层级清楚。注意：不要在列表项间插入未缩进的内容，否则会破坏列表连续性。 ## 链接、图片与引用 链接文字应能独立表达目标，不要使用“点击这里”。格式为 `[文字](url "标题")`，标题可省略。图片格式为 ``，替代文字要描述图片内容；图片无法加载时，替代文字就是可读信息。引用用 `>`，适合放提示、风险说明或摘录。 适用场景：外部资料引用、截图说明、警告信息。步骤：先贴 URL，再补可读文字；图片上传到稳定图床或仓库目录，不用本地临时路径。注意：发布前逐一点击链接确认可达。 ## 代码块与表格 代码块用三个反引号围住，并在开头标注语言，例如 `bash`。表格使用 GFM 表格，分隔行用 `| --- | :---: |` 控制左对齐、居中或右对齐；列数必须前后一致。单元格内需要显示 `|` 时写成 `\|`。表格适合参数对照、兼容性矩阵，不要用来做复杂页面布局。 适用场景：示例代码、配置片段、版本兼容表。判断标准：代码语言标注正确，表格每行列数一致。注意：CommonMark 不包含表格语法，若目标平台只支持 CommonMark，应改为列表或段落；GFM 平台如 GitHub 才使用表格和任务列表。 ## 转义与发布前检查 需要显示 Markdown 符号本身时，用反斜杠转义，例如 `\*`、`\_`。发布前至少检查：标题层级是否跳级、链接是否可打开、图片是否显示、代码块语言是否正确、表格列数是否一致、列表缩进是否错乱。建议先在目标平台或本地渲染一次。 适用场景：发布到 GitHub、CMS、静态站点前的最终检查。步骤：从目录开始核对层级，再逐节检查行内与块级元素。注意：不同渲染器对空行、内联 HTML、任务列表支持存在差异，优先使用基础语法保证兼容。 合格 Markdown 排版不是堆叠语法，而是用最小且一致的结构，让文档在多数渲染器中都能稳定呈现。优先保证层级、缩进、链接与代码块正确，再考虑表格、任务列表等扩展语法。