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 輔助整理。*