Markdown 列表层级错了怎么办：按正文起始列检查缩进

核心机制：为什么“固定两空格或四空格”并不通用

常见经验常建议“子列表缩进 2 个空格”，这在无序列表下通常可行，但遇到多位有序列表时便会失效。根本原因在于标准解析器依赖正文起始列（First Content Column）判定嵌套边界：

1. 无序标记占位较窄：符号 - 、* 或 + 加尾随空格共占 2 列，正文从第 3 列开始。子项缩进 2 至 4 个空格，标记符号即可落在第 3 列或更深位置，被识别为子节点。
2. 多位编号标记列宽递增：

- 编号 1. 包含数字、英文句点与空格，共占 3 列，正文始于第 4 列。 - 编号 100. 包含三位数字、句点与空格，共占 5 列，正文始于第 6 列。 - 若在 100. 下仅缩进 2 个空格，子项标记仅处于第 3 列，仍在父项标记的列宽内，解析器无法判定其属于父项内容，往往直接退回为顶格新列表。

GitHub 官方格式文档之外，列表规则应以CommonMark 规范及目标编辑器的实现为准。编辑器粘贴或转换内容也可能改变原有层级，不能只检查屏幕上的缩进。因此，不能断言固定两空格或四空格通用。

标准排查步骤：按正文起始列对齐缩进

遇到列表层级异常时，可按以下四步排查：

1. 定位父项正文起始列：观察父项标记及其后空格的总字符数。如 1. 之后正文在第 4 列；100. 之后正文在第 6 列。
2. 对齐子项标记首字符：调整子项前导空格，使其标记首字符对齐父项的正文起始列（如 100. 后的子项需前置 5 个空格对齐第 6 列）。
3. 统一段落与代码块缩进：父项若包含跨行文本，后续段落首行需缩进至正文起始列；若需在列表项内嵌入代码片段，请参考 Markdown 代码块排版指南 保持同层缩进，避免未对齐的代码围栏中断列表解析。
4. 核对空行之后的缩进：空行可能使列表变为松散列表，但不能把“两个空行”当作 CommonMark 中结束列表的通用规则。重点检查空行后的段落或子列表是否仍缩进到父项内容范围。

最小可复现对比：多位编号、段落延续与空行陷阱

通过以下最小可复现案例，可以直观对比结构差异：

多位编号缩进对比：

<!-- 错误：机械缩进 2 格，未达第 6 列基准 -->
100. 核心模块测试
  - 子任务未对齐（解析异常）

<!-- 正确：按正文起始列缩进 5 格，对齐第 6 列 -->
100. 核心模块测试
     - 子任务对齐成功（正常嵌套）

段落换行与空行陷阱：

1. 系统初始化说明
   这是属于第一项的延续段落，首行缩进 3 格对齐正文。

   - 嵌套配置子项（紧随单空行，保持结构完整）


2. 第二项；在目标解析器中核对编号和层级，不仅凭空行数量判断

无法仅靠增减空格解决的边界情况

部分列表错乱并非空格数量不足引起，排查时需注意以下底层干扰：

• Tab 与空格混用：编辑器显示的 Tab 宽度可能与解析器计算缩进的方式不同。源码混用会导致列计算混乱，排查时应先将制表符全量转为空格。
• 全角空格误输入：中文输入法下的全角空格（\u3000）在视觉上呈现缩进，但解析器将其视作普通字符，无法形成语法缩进。
• 富文本编辑器状态冲突：如 MarkText 等编辑器在可视化转换 AST 时，若底层对嵌套节点处理存在缺陷（如 issue #4704 涉及的逻辑），可能在保存时重写空格。此时需切换为纯源码模式保存或精简过深嵌套。

验证验收方法与多端导出检查

完成缩进对齐后，按以下三项标准进行验收：

1. 查看空白字符：在文本编辑器中开启“显示空格与制表符”，确认缩进全部为半角空格，无制表符与全角字符。
2. 核验 HTML 结构：预览生成的 HTML 代码，合法的子列表必须是 <ol> 或 <ul> 完整嵌套在父级 <li> 标签内部，而非并列分离的独立标签。
3. 跨端导出对照：不同平台的渲染引擎对边界情况的宽容度不同，发布前可参阅 Markdown 导出指南 导出 HTML，核对最终视觉层级与编号连续性。

--- *署名：AI Lab 内容维护，AI 辅助整理。*