MAX_PATH 260 字元限制解密|路徑過長怎麼解

文章屬性:科技冷知識 / 規格解析
核心結論:260 不是 NTFS 的極限,而是 Win32 API 對「路徑字串」的長度約定——官方把 MAX_PATH 定義為 260 個字元,拆開來是磁碟機代號那三個字元、256 個字元的路徑本體,再加一個看不見的結尾 null 字元。Windows 10 1607 之後官方已開放解除,但登錄值與程式自己的資訊清單(manifest)兩個條件缺一不可。
適用對象:被「檔案名稱太長」「路徑過長」擋住的 Windows 使用者、常把專案 clone 到深層資料夾的工程師

📌 快速答案

一句話答案:MAX_PATH 260 字元是 Win32 API 的路徑字串上限(3+256+1);改用 Unicode 版 API 加上 \\?\ 前綴,單次呼叫最長可達約 32,767 個字元。

🔍 故事的起點

複製一個資料夾,跳出「檔案名稱太長」;解壓縮到桌面,某幾個檔案就是解不出來;clone 一個目錄結構很深的 Git 專案,直接卡死在 checkout。這些症狀的源頭是同一個數字:260。微軟官方文件甚至直接把 Git 拿來當範例,寫明「把檔名很長的 Git 儲存庫 clone 到一個本身名字就很長的資料夾裡」正是會撞到這個限制的典型情境。

有趣的是,這個數字跟你的硬碟、跟 NTFS 幾乎沒有關係。它是 Windows API 對「一個路徑字串最長會有多長」所下的定義。官方文件並沒有交代 260 這個數字的由來,但它與 8.3 檔名的牽連留有明證:官方規定用 API 建立目錄時,路徑必須短到還能再附加一個 8.3 檔名(主檔名 8 個字元、副檔名 3 個字元,含中間那個點共 12 個字元),這條規則至今仍然生效。跟 System32 放 64 位元、SysWOW64 反而放 32 位元一樣,這是相容性包袱留下的化石,不是技術做不到。

🧪 原理拆解

260 到底怎麼算出來的

微軟官方文件寫得很清楚:在 Windows API 中,路徑的最大長度就是 MAX_PATH,而 MAX_PATH 定義為 260 個字元。本機路徑的結構依序是:磁碟機代號、冒號、反斜線、以反斜線分隔的各層名稱,最後是一個結尾的 null 字元。官方舉的例子是 D 槽上的最長路徑會長成 D:\<256 個字元的路徑字串><NUL>。

換句話說,260 這個數字是這樣湊出來的:D:\ 佔 3 個字元、路徑本體 256 個字元、結尾那個看不見的 null 字元佔 1 個。3 + 256 + 1 = 260。它從頭到尾都是字串緩衝區的長度約定,不是磁碟上的物理極限。

卡住的是 API,不是檔案系統

同一份官方文件接著說:Windows API 裡有許多函式同時提供 Unicode 版本,可支援「延伸長度路徑」,總長度最多 32,767 個字元;要使用這種路徑,得在前面加上 \\?\ 前綴,例如 \\?\D:\<很長的路徑>。網路芳鄰的 UNC 路徑則用 \\?\UNC\server\share 的寫法。

\\?\ 的作用是叫 Windows API 關閉所有字串剖析,把後面的字串原封不動丟給檔案系統。官方也提醒 32,767 只是近似值,因為系統在執行時可能把前綴展開成更長的字串,而展開後的長度一樣算進總長。至於路徑中的每一層名稱,長度上限由 GetVolumeInformation 回報,常見值是 255 個字元。

MAX_PATH 260 的四個關鍵數字:260、32767、255、248 資訊圖 — MAX_PATH 相關的四個關鍵數字(來源:Microsoft Learn Win32 文件,2026-07-25 查證)

三個幾乎沒人講的細節

第一,相對路徑永遠回到 260。官方明載 \\?\ 前綴不能搭配相對路徑使用,因此相對路徑一律受 MAX_PATH 限制——這也是為什麼有些程式明明支援長路徑,你用相對路徑操作時卻還是失敗。

第二,建立資料夾比開檔案更早卡住。官方規定用 API 建立目錄時,路徑不得長到「無法再附加一個 8.3 檔名」,也就是不能超過 MAX_PATH 減 12(260 − 12 = 248)。8.3 檔名的幽靈,到今天還在扣你 12 個字元。

第三,shell 與檔案系統的要求不一樣。官方直白寫著:你有可能用 Windows API 建出一個路徑,而 shell 使用者介面(也就是檔案總管那一層)根本無法正確解讀。檔案存在、指令進得去、圖形介面卻打不開,並不是你的電腦壞了。

🔓 Windows 10 1607 之後,官方怎麼正式解除

從 Windows 10 1607 版開始,官方已把 MAX_PATH 限制從許多常用的 Win32 檔案與目錄函式中移除(例如 CreateFileW、FindFirstFileW、MoveFileW、CreateDirectoryW 等),但應用程式必須主動選擇加入(opt-in)新行為。官方明列的條件只有兩個,缺一不可:

條件	內容	誰負責
① 登錄值	`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem` 下的 `LongPathsEnabled`(REG_DWORD)必須存在且設為 `1`	使用者 / IT
② 資訊清單	應用程式的 manifest 必須含有 `longPathAware` 元素並設為 true	軟體開發者

(重新開機不是官方列的第三個條件,而是官方註記的「可能需要」——原因見下方第三點。)

重點摘要:

這個登錄值只會影響已經改寫過、宣告自己支援長路徑的程式;官方特別加註「這不是會影響所有應用程式的變更」。
條件②握在軟體開發者手上,不是你改登錄檔就能替別人的程式決定。這也是「我明明開了 LongPathsEnabled,某些程式還是不行」最常見的原因。微軟並未逐一公布哪些內建程式已宣告 longPathAware;不過 Git for Windows 現行的設定文件直接寫明,長路徑「不被 Windows 檔案總管、cmd.exe 與 Git for Windows 工具鏈支援」,這是目前少數可查的具名說法。
因為登錄值是每個程序各自快取、程序執行期間不會重讀,官方建議可能需要重新開機,才能讓系統上所有程式都認得這個值。
同一項設定也可以走群組原則:官方原文路徑為 Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 long paths(中文介面約為「電腦設定 > 系統管理範本 > 系統 > 檔案系統 > 啟用 Win32 長路徑」,實際節點名稱依系統語言版本可能略有不同),企業環境亦可用 Microsoft Intune 的原則設定服務提供者(Policy CSP)派送。
官方同時提供可直接匯入的 .reg 內容,等同於手動建立上述登錄值。

⚠️ 動手前先讀:以下操作會修改系統登錄檔。執行前請先建立系統還原點,或至少匯出 FileSystem 這個機碼備份(在登錄編輯程式中對機碼按右鍵 →「匯出」)。登錄檔改壞可能導致系統或應用程式無法正常運作。

🛑 停止條件清單(符合任一,請勿繼續):不確定自己 Windows 的版本是否為 Windows 10 1607 以上、尚未完成備份或還原點、公司或學校管控的設備且未取得 IT 授權、對登錄編輯程式的操作不熟悉、看到的機碼路徑與本文不符。

官方提供的 .reg 內容如下:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

🧰 不想改設定時的三個現場解法

先給結論:多數人其實不需要動登錄檔,把路徑縮短或換一個支援長路徑的工具就解決了。

把起點往上搬。專案從 C:\Users\你的名字\Desktop\2026\客戶\... 移到 C:\src\,一口氣省掉數十個字元,這是最快也最不痛的解法。
Git for Windows 有自己的開關。msysGit 專案 wiki(已封存,最後編輯於 2017 年)記載:長路徑支援預設為關閉,可用 git config core.longpaths true 為 C 語言實作的 git 指令開啟,但以指令稿實作的 git 指令仍可能失敗,風險自負。這條至今未過時——Git for Windows 現行的 core.longpaths 設定文件仍寫著預設關閉。
換工具,並學會判斷工具行不行。判準就是官方那條規則:程式的 manifest 有沒有宣告 longPathAware。壓縮軟體、同步工具、備份程式之間差異很大,實務上請以「同一個超長路徑實際跑一次」來驗證,不要憑軟體名氣推論——需要一套壓縮工具時,可參考 7-Zip 完整教學。

🔙 萬一翻車:回退步驟

情境一:改了登錄值,長路徑還是不會動。 這通常不是翻車,而是條件②未成立(該程式沒有宣告 longPathAware),或尚未重新開機。先重開機再測一次;仍不行就是程式本身不支援,回退設定並改用其他做法。
情境二:改完之後某些舊程式行為異常。 把 LongPathsEnabled 改回 0(或刪除該值),重新開機即可回到原本行為;若當初是用群組原則設定,把該原則改回「未設定」再重新開機。
情境三:登錄檔操作出錯、系統不穩。 用先前匯出的 .reg 備份檔還原該機碼,或以系統還原點回到修改前的狀態。若已無法正常進入系統,可從 Windows 復原環境(WinRE)執行系統還原。

💡 總結:冷知識延伸

站長我最喜歡 260 這個數字的地方,是它的組成完全可以照官方定義拆開來看:3 個字元給磁碟機代號、1 個字元給結尾的 null、建資料夾時另外被扣掉的 12 個字元留給 8.3 短檔名。至於為什麼是 260 而不是別的數字,微軟官方文件從頭到尾沒有解釋,坊間流傳的 DOS 淵源說法也查不到官方一級來源可以佐證——一個每天擋住無數人的數字,官方居然沒留下說明,這件事本身就很冷知識。

另一個少有人注意的細節是:官方文件明說,檔案系統把路徑與檔名當成不透明的 WCHAR 序列處理,不需要做 Unicode 正規化。所以就 Unicode(W)版 API 而言,「路徑長度」算的是字元數而不是位元組數,中文檔名不會因為佔比較多位元組就更快撞牆;不過官方在說明那個結尾 null 時特別加了「目前系統字碼頁」的限定語,舊的 ANSI(A)版 API 並不適用同一結論。

❓ 常見問題

Q:我照著開了 LongPathsEnabled,為什麼檔案總管還是說路徑太長?

多半是官方的條件②沒被滿足。登錄值只是打開系統這一側的門,程式那一側必須在自己的 manifest 宣告 longPathAware,兩者同時成立才生效;而且登錄值會被每個程序快取,通常得重新開機。這個決定權在軟體開發者手上,不在你的登錄檔;微軟未公布內建程式的宣告狀況,實際行不行請以自己機器上的實測為準。

Q:改這個登錄值有風險嗎?

風險面比想像中窄——官方明載它只影響已宣告支援長路徑的程式,對其他程式不生效。真正的風險在「動登錄檔」這個行為本身:改錯機碼、改到別的值,才是問題所在。所以請先備份、先建立還原點,並遵守上面的停止條件清單。

Q:NTFS 到底能存多長的路徑?

官方口徑是約 32,767 個字元(Unicode 版 API 搭配 \\?\ 前綴),單層名稱常見上限 255 個字元。260 從來就不是儲存層的極限。

Q:為什麼建立資料夾比開啟檔案更早卡住?

因為官方規定建立目錄時路徑必須留得下一個 8.3 檔名,實際可用長度是 MAX_PATH 減 12,也就是 248 個字元。

📅 本文查證戳記:2026-07-25 依據 Microsoft Learn Win32 官方文件撰寫,未包含站長第一手實測數據。
微軟若調整長路徑的預設行為或群組原則位置,本文會同步更新。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Maximum Path Length Limitation — Microsoft Learn(Win32 apps) — 2026-07-25 查證
Naming Files, Paths, and Namespaces — Microsoft Learn(Win32 apps) — 2026-07-25 查證

📖 第二級|開源專案文件:

core.longpaths 設定說明 — Git for Windows 現行文件(Documentation/config/core.adoc) — 2026-07-25 查證
Git cannot create a file or directory with a long path — msysGit 專案 wiki(已封存,2017-03 最後編輯) — 2026-07-25 查證