精通Markdown列表：CommonMark與GitHub Flavored Markdown (GFM) 縮排標準
Markdown列表轉譯的技術基礎
Markdown已成為現代軟體文件、技術規格書、個人知識庫以及開發者日常溝通的標準標記語言。雖然單層無序列表（- 項目）與有序列表（1. 項目）看似簡單，但在建置深度嵌套的多層文件大綱時，會引入極高格式複雜度。不同的Markdown解析器（如CommonMark、GitHub Flavored Markdown (GFM)、Python-Markdown和Pandoc）在列表符號選擇、Tab與空格比例以及子區塊縮排方面都有著嚴格而微妙的規則。
當列表在不同的文字編輯器（如VS Code、Sublime Text、Xcode、Apple Notes或Microsoft Word）之間相互貼上時，經常會出現隱蔽的縮排錯誤。子項上只要缺失一個空格，Markdown編譯器就會將嵌套的子節點誤判為主層級項目或孤立的段落區塊。Utiliome的嵌套列表與縮排格式化工具透過解析輸入文字的抽象語法樹（AST），並重新產生符合規範的標準Markdown，徹底消除這些解析異常。
縮排規則：2空格 vs 4空格指南
技術文件設計中最常見的爭議之一是：子列表究竟應該按層級縮排2個空格還是4個空格。這取決於目標Markdown解析器的規範要求：
2空格縮排規則（標準GFM與Prettier）： 在GitHub、Docusaurus、Nextra和Obsidian等現代Web文件生態系統中，每層縮排2個空格是公認的標準。2空格規範可使子項內容與父項文字的起始位置對齊：
- 頂層項目 1 - 嵌套子項目 1.1 - 嵌套子項目 1.2 - 深度嵌套孫項目 1.2.1 - 頂層項目 24空格縮排規則（嚴格CommonMark與Python-Markdown）： 嚴格的CommonMark實作要求有序列表內部的子區塊、程式碼片段和嵌套列表必須縮排4個空格（或1個完整的Tab），以確保父區塊的包含關係：
1. 工作流程中的第一步 - 關聯的子項目 A - 關聯的子項目 B 2. 工作流程中的第二步Tab與空格混用的陷阱： 混用實體Tab字元（
\t）與ASCII空格字元（\x20）是導致Markdown文件轉譯排版崩潰的首要原因。Web轉譯引擎對Tab的解析並不一致（通常顯示為4或8個字元寬度），導致嵌套項出現視覺錯位。Utiliome會根據您的設定偏好，自動將所有Tab字元轉換為統一的空格字串。
項目符號規範化與有序序列重排
Markdown支援三種不同的無序列表符號：連字號（-）、星號（*）和加號（+）。雖然三者都能產生有效的HTML無序列表元素（<ul>），但在同一文件中混用不同符號會造成視覺混亂，且無法透過自動化Lint檢查（例如 markdownlint 的 MD004 規則）。
此外，在反覆編輯的過程中，有序列表的編號經常被打亂。作者經常在列表中間貼上新項，或者依賴重複的 1. 語法：
<!-- 未格式化 / 混亂的輸入 -->
* 特性 A
- 特性 B
+ 特性 C
1. 初始步驟
1. 第二步（從草稿複製）
4. 順序混亂的步驟
Utiliome格式化工具會將所有無序列表符號統一為您選擇的字元（例如全部規範為 -），將有序列表重新重排為連續遞增的數字（1.、2.、3.），或根據您團隊的程式碼規範統一重排為乾淨的增量形式。