CMD 中的 tree 指令會在螢幕上繪製目錄結構，但輸出會隨著你捲動而滑過，透過聊天視窗貼上時可能會遺失它的方框繪製字元，並且也無法保證同一個資料夾執行兩次後，在複製出來時看起來會一模一樣。若要在 CMD 中取得一個能以穩定文字形式存活下來、進入 README、議題或程式碼審閱的目錄樹，可靠的工作流程是從 shell 傾印一串嚴格的相對路徑清單，將該清單送入 Directory Tree Generator，然後挑選一個符合輸出貼上位置的連接線樣式。這個工具會把每行一條的相對路徑轉成一個顯示的根節點加上排序過的分支，由於排序依據是 UTF-16 字碼單元而非地區設定、修改日期或輸入順序，因此同樣的輸入一定會產生同樣的渲染輸出。解析、驗證、排序、渲染和剪貼簿複製都在當前分頁中執行，所以檔案名稱與資料夾結構永遠不會離開產生該清單的機器。

how to get directory tree in cmd
如何以可分享文字形式取得 CMD 中的目錄樹

為何內建的 tree 指令在可分享輸出方面有所不足

CMD 原生的 tree 指令是為單一消費者設計的:你正坐在前面的終端機。預設模式使用的 Unicode 字元，在某些 Windows 主控台上會處理錯誤，即使能正確渲染，結果也只是螢幕輸出，而非穩定的文件。切換到 tree /A 會把那些字元換成 +、- 與 \ 等字元，大多數複製貼上的路徑都能存活，但底層的限制依然存在。

  • 排序遵循底層檔案系統，而 NTFS、ReFS、exFAT 與網路共用之間各不相同。對同一個資料夾執行同一道指令兩次，可能會產生明顯不同的順序。
  • 當某一層的子項目順序改變時，縮排在不同次執行之間可能會位移，這會讓所產生樹狀圖的差異比對變得雜亂。
  • 不支援合併來自多個根的樹狀圖。tree 一次只能走訪一個根路徑。
  • 字元不一定能在往返經過聊天用戶端、電子郵件或網頁表單後仍保持原樣。即使是 ASCII 的分支字元，有時也會進入會剝除或替換它們的渲染器中。
  • 在發布之前，沒有辦法在不手動編輯已經格式化好的區塊的情況下，遮蔽樹狀圖中的部分內容。

對於最終要放進 README、議題範本或 pull request 描述中的樹狀圖來說，你真正想要的是穩定的文字，每次從同一份來源清單重新產生時，欄位都能以同樣的方式對齊。這個目標位於 tree 上游一步的地方，也就是一份嚴格的相對檔案路徑清單。

什麼時候路徑清單勝過在本機執行 tree

即使 CMD 已經打開並準備就緒，仍有些實際情況下執行 tree 是錯誤的起點。

  • 你無法在目標機器上取得 shell 存取權，但你手上有一份清單、匯出檔或同事貼過來的內容。路徑清單是你唯一能取得的輸入。
  • 你想要為一份對客戶的文件遮蔽樹狀圖的部分內容。從路徑清單中抹除名稱，比清理一份已經渲染好的樹狀圖更快且更不易出錯。
  • 你想要記錄的資料夾位於不同的作業系統、建置產出物或未掛載為磁碟機的備份之中。
  • 你需要確定性的輸出。今天從一份乾淨的路徑清單所產生的樹狀圖，明天會逐位元組地以同樣方式渲染，不受底層檔案系統如何排序目錄項目所影響。
  • 樹狀圖太深，終端機無法以整齊的縮排顯示。產生器會從單一小數點根節點繪製前綴，並維持在其輸出上限之內，因此很深的樹狀圖仍可解析，而不會在某個字元中間換行。

在上述每一種情況下，務實的做法是跳過 CMD 的 tree，直接從路徑清單開始。

從 CMD 傾印一份乾淨的相對路徑清單

  1. 開啟 CMD 並切換到專案根目錄，例如 cd "C:\Users\you\projects\demo"。
  2. 若只要列出檔案，請執行 dir /S /B /A-D。/S 旗標會遞迴，/B 會去除頁首並使用裸路徑，/A-D 會排除目錄項目，使每一行都是一個檔案。
  3. 若要同時列出檔案與資料夾，請執行 dir /S /B。在裸格式中，資料夾行的結尾沒有尾端斜線;檔案行的結尾則是檔案名稱。
  4. 在標題列上按右鍵，選擇 Mark，拖曳以選取該區塊，按 Enter 將它複製到剪貼簿。
  5. 將該區塊貼到純文字編輯器中。從每一行移除前端的絕對路徑前綴，使每一行都相對於專案根目錄，例如把 C:\Users\you\projects\demo\ 全部取代為空字串。
  6. 確認分隔符號樣式在每一行之間都一致。如果有任何一行使用正斜線，而其他行使用反斜線，請在貼到工具之前先把清單統一。
  7. 儲存清理過的清單。它現在看起來應該會像一欄路徑，例如 src\index.ts、src\components\Button.tsx 和 README.md，以換行符號分隔且不含空白行。

這份清單就是產生器預期的輸入。在此階段移除空白行、重複的分隔符號、點段落以及任何絕對路徑前綴，可以避免產生過程中最常見的拒絕訊息。

使用 Directory Tree Generator 建立可分享的樹狀圖

  1. 在你打算複製結果的同一個瀏覽器分頁中開啟 Directory Tree Generator。在解析、排序、渲染或寫入剪貼簿期間，沒有任何資料會離開這個分頁。
  2. 將清理過的路徑清單貼到輸入區，每行一條路徑，每一行使用相同的分隔符號樣式。將分隔符號切換設為反斜線(適用於 Windows 風格路徑)或正斜線(適用於 POSIX 風格路徑)。
  3. 挑選連接線樣式。在 GitHub、Notion 和現代的 Markdown 檢視器中使用 Unicode(├──、└──、│)。在終端機、嚴格篩選器後方的程式碼區塊，或會剝除非 ASCII 字元的 wiki 中，則使用 ASCII(|--、`--、|)。
  4. 點擊 Generate tree。工具會以換行符號分隔，移除每行 CRLF 結尾的單一 carriage return，並拒絕空白行、重複的路徑、不符合切換設定的分隔符號、點段落、父段落、絕對路徑，以及任何跨越段落或字碼單元邊界的行。
  5. 讀取節點數與渲染後的樹狀圖。輸出永遠以單一小數點作為顯示的根節點開頭;在每一層中，目錄會出現在檔案之前;同層項目則依 UTF-16 字碼單元排序。
  6. 點擊 Copy。完整的樹狀圖會非同步地送到剪貼簿。如果瀏覽器拒絕剪貼簿權限，渲染後的樹狀圖仍可選取，以便使用 Ctrl+C 或 Cmd+C 手動複製。
  7. 將結果貼到 README、議題範本、架構說明或程式碼審閱中。無論目的地的格式器如何安排程式碼區塊，連接線樣式與排序都會與工具所產生的一致。

如果有某一行被拒絕，工具會回報該違規行的行號，而不會丟棄其餘的輸入。修正該行後再點一次 Generate;絕對不會產生部分樹狀圖。

產生器強制執行的輸入規則

限制是明確的，驗證是嚴格的，被拒絕的輸入絕不會被默默截斷。了解確切的規則可以避免最常見的意外。

限制條件 允許值 在邊界時的行為
輸入總大小 100,000 UTF-16 字碼單元 在上限時接受;再多 1 個字碼單元會拒絕此次執行
路徑行數 2,000 條路徑 第 2,001 行會連同其行號一起被拒絕
每條路徑的段落數 128 個段落 第 129 個段落會拒絕該路徑
段落長度 255 UTF-16 字碼單元 再多 1 個字碼單元會拒絕該段落
渲染輸出 500,000 UTF-16 字碼單元 渲染會中止，而不是截斷

除了數字上限之外，工具也會拒絕包含以下情況的清單:空白行(包括最後一筆項目之後的尾端空白行)、在同一個切換設定下混用分隔符號的路徑、絕對路徑、前置分隔符號、Windows 磁碟機根根形式、因重複或尾端分隔符號而產生的空段落、. 或 .. 段落、名稱中包含 ASCII 控制字元、完全重複的路徑、檔案/目錄衝突，或任一方向的 prefix 衝突。含有一般空白與點的名稱(例如 .env.example、data file.json、archive.v1 和 README draft.md)會依照輸入原樣保留，字母大小寫也會保留，這就是為什麼 Docs/readme.md 和 docs/readme.md 會被視為兩個不同的項目。

Unicode 與 ASCII 分支字元的比較

兩種連接線樣式都能用於記錄目錄結構;選擇的重點在於輸出會在哪裡渲染，而非樹狀圖本身代表的內容。

  • Unicode 模式使用方框繪製字元:中間的同層項目用 ├──，群組中最末的同層項目用 └──，父項目下的垂直縮排則用 │。在 GitHub、GitLab、Bitbucket、Notion、Slack 程式碼區塊以及大多數現代的 Markdown 檢視器中都能自然閱讀。
  • ASCII 模式使用一般的鍵盤字元:|--、`-- 與 |。在缺少方框繪製支援的地區設定或字型的終端機中、在經過嚴格 UTF-8 剝除後的貼上程式碼區塊中，以及在純文字電子郵件或 wiki 渲染中，都能可靠閱讀。

在兩者之間切換需要重新點擊一次 Generate tree。只要連接線切換一變動，工具就會清除任何先前的輸出，因此舊的樹狀圖不會被誤認為是當前設定的結果。

Privacy, sorting, and what the result actually represents

The generator is a deterministic text transformer, not a filesystem scanner. Knowing that shapes realistic expectations about what the output can and cannot say about the source project.

  • Processing location. Parsing, validation, sorting, rendering, and clipboard writing all happen in the current browser tab. File names and folder structure are not uploaded to Lizely or sent to an external API.
  • Sorting. Within each level, directories come first, and within the directory group and the file group, names are compared by UTF-16 code units. The ordering is deterministic across supported browsers and independent of locale, operating-system collation, input order, modification time, and filesystem metadata.
  • Root convention. The output always begins with a single line containing a dot, the displayed root. Every child of that root is one segment deep, regardless of how the source paths were nested.
  • Case sensitivity. Comparisons are exact JavaScript string compares, so Docs/readme.md and docs/readme.md remain distinct. If the same tree is later rendered on a case-insensitive filesystem such as NTFS, macOS HFS+, or APFS, the displayed ordering still matches what the generator produced.
  • What the tool does not do. It does not read your disk, read folder metadata, verify that a path exists, label symlinks, calculate sizes, redact secrets, inspect ignore files, or compare the typed list with a real repository. Review the result before publishing; project trees can leak module names, customer names, or deployment layouts even when file contents are absent.

For a CMD-driven workflow, the final loop is straightforward: dump a clean relative path list, paste into Directory Tree Generator, pick a separator and connector style, generate, review the node count, and copy. That path covers the trip from the console output of tree to a stable, paste-ready directory tree in your documentation.

If you're weighing options, How to Get Excel Link Targets as a Plain-Text List covers this in detail.

If you're weighing options, Convert Text to HTML Paragraphs in Bulk Without a Server covers this in detail.