Windows 11 如何开启长路径？彻底解决260字符路径限制-代码聚汇网

Windows 11 如何开启长路径？彻底解决260字符路径限制

哗啦啦的小流弊·2026-08-29·阅读 22 GEO检测（免费）

Windows 11长路径260字符

|难度：普通|阅读约 25 分钟

1. 先弄明白：Windows的260字符路径限制，到底卡在哪

如果你搞过前端依赖安装、解压过大型源码包，或者管理过深度嵌套的工程目录，大概率碰到过这样一个报错：

无法删除。文件名或扩展名太长。

路径太长：目标路径超过了最大路径长度。

这个"最大路径长度"，指的就是从Windows XP时代一直传下来的MAX_PATH = 260字符限制。260这数字怎么来的？早期Windows文件系统API内部用char数组存路径，长度为260，其中包含盘符、冒号、反斜杠、目录名、文件名和结尾的空字符。设计当初觉得够用，问题是嵌套目录一深，或者文件名一长，很容易就把额度耗光。

在Windows 11上，这种情况更常见了。Node.js的node_modules深层依赖动辄几百个字符，Git仓库的子模块嵌套、.NET项目的bin\Debug\net8.0-windows\生成目录，都会让你撞上这堵墙。微软其实从Windows 10 1607版本就开始提供Win32长路径支持，但默认关闭，Windows 11继承了这一设定。所以很多人在Win11上换新电脑、装新环境，照样会遇到这个困扰。

这篇文章就把Win32长路径这件事彻底讲透：怎么开启，开启后哪些场景有效、哪些场景无效，以及遇到"明明开了还是报错"时怎么排查。我会直接给可操作步骤，也会说明每个步骤背后的原因，保证你按着做完之后，心里有底。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 开启长路径的三条路：图形界面、注册表、命令行

在Windows 11上开启Win32长路径，本质上就是改一个注册表项：

code复制HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
LongPathsEnabled = 1

就这么一个DWORD值，0是关闭，1是开启。所有的操作方式都绕不开这个注册表项，只是改的方式不同。下面我把三种方式都列出来，你任选一个即可。

2.1 组策略编辑器：适合有Pro/Enterprise版本的用户

按Win + R输入gpedit.msc回车，路径依次展开：

code复制计算机配置 → 管理模板 → 系统 → 文件系统

右侧有一个启用 Win32 长路径策略，双击打开，设为已启用，确定。这一步本质就是在帮你写上述注册表项。

这里有个注意点：组策略改了之后，已开着的程序不会立刻生效。注册表变更需要重启电脑，或者重启所有依赖Win32路径的应用程序才能识别。我建议改完直接重启，省得后面排查时怀疑是不是自己改漏了。

2.2 注册表编辑器：最直接、所有版本通用

Windows 11家庭版没有组策略编辑器，注册表这条路是通用方案。按Win + R输入regedit回车，导航到：

code复制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

右侧找到LongPathsEnabled，没有就右键→新建→DWORD（32位）值，命名LongPathsEnabled。把数值数据改成1，基数选十六进制，确定后重启。

2.3 命令行：批量部署和脚本自动化最推荐

如果你需要给多台机器配置，或者想把这一步写进自动化脚本，用管理员身份打开PowerShell或终端，执行：

powershell复制New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

或者用传统的reg add：

cmd复制reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled /t REG_DWORD /d 1 /f

前者适合PowerShell脚本，后者适合批处理。执行完可以马上验证一下：

powershell复制Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled"

返回的LongPathsEnabled是1，说明写成功了。

2.4 家庭版用户的补充说明

如果你用的是Windows 11家庭版，gpedit.msc打不开是正常的，因为组件没装。直接用注册表方式即可，效果没差别。网上有教程教人绕路装回组策略组件，我不太推荐，为一个开关大动干戈不划算，注册表改一个值而已，没必要。

3. 开启之后，为什么有些软件依然报"路径太长"

这是被问得最多的一个问题。很多人改完注册表、重启完，发现某个老软件还是报错，就以为设置没生效。实际上，Win32长路径的启用只是给系统开了一个"允许"的口子，程序自身得配合才行。

3.1 核心门槛：manifest里的longPathAware

Windows 10 1607引入长路径支持时，设计了一个兼容性机制：只有当应用程序在自身manifest中声明了longPathAware，系统才会把长路径行为应用到它身上。没声明这个标记的老程序，即使系统层面开了LongPathsEnabled=1，调用的Win32 API也依然按260字符的旧逻辑处理。

这就像高速路修好了，但你的车没装ETC，还是只能走人工车道。程序manifest就是那个ETC标签。

用Visual Studio开发的程序，在app.manifest中加这一段即可：

xml复制<application xmlns="urn:schemas-microsoft-com:asm.v3">
  <windowsSettings>
    <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
  </windowsSettings>
</application>

不加这一行，程序调用的CreateFileW、GetFullPathNameW这些核心API依然会在260字符处截断。

3.2 哪些程序天然支持，哪些大概率不支持

天然支持或经过适配的：

文件资源管理器（Windows 11自带，开启后即可处理长路径）
PowerShell（配合\\?\前缀使用）
现代IDE和代码编辑器：VS Code、Visual Studio 2022（需开启相关选项）、IntelliJ系列
Git for Windows（需额外设置core.longpaths true，见后文）
.NET Core / .NET 5+ 应用，以及显式设置了LongPathAware的.NET Framework 4.6.2+应用

大概率不支持的：

很多老旧的原生Win32程序（2016年之前编译且未重新适配的）
部分安装程序（InstallShield、老版NSIS打的包）
某些使用低级文件API的磁盘工具、压缩软件

这跟Windows 11版本没关系，是程序编译时决定的。你可以在Windows 11上跑一个2005年编译的软件，它照样不认识长路径。

3.3 开发者的自查方法

如果你自己是开发者，不确定程序有没有声明longPathAware，可以用Visual Studio自带的工具或dumpbin查看：

cmd复制dumpbin /dependents yourprogram.exe

不过dumpbin不直接显示manifest。更直接的方法是用mt.exe（Manifest Tool）或者直接在代码里测试：用程序创建一个超过260字符的目录，能成功就说明支持。

csharp复制Directory.CreateDirectory(@"C:\Users\Public\" + new string('a', 200) + @"\" + new string('b', 100));

能跑通就OK，报错就是没适配。

4. 实际使用场景实测：文件资源管理器、Git与PowerShell

4.1 文件资源管理器在Win11上的表现

Windows 11的文件资源管理器在系统开启长路径后，大多数情况下可以直接创建、重命名、删除超长路径的文件。注意只是"大多数情况"，因为资源管理器本身有额外的策略和组件，有些Shell扩展（比如右键菜单里的第三方压缩工具）依然有自己的限制。

实测中我还发现一个规律：在资源管理器地址栏直接输入超长路径，会比在文件夹里逐层点击进入更稳定。地址栏用的是底层解析，逐层单击涉及更多Shell组件。

如果你在资源管理器里还是碰到"文件名或扩展名太长"的提示（没有中间层拦截的程序），那就需要检查Application Verifier或者Process Monitor看看是哪一个DLL弹出的窗口。

4.2 Git仓库处理深度依赖的常规配置

前端开发者在Windows上拉取Node.js项目，必做的一步就是设置Git的长路径支持，否则npm install极易失败：

cmd复制git config --global core.longpaths true

这是Git自己的配置项，跟系统注册表的LongPathsEnabled是两套机制。前者让Git在内部处理路径时用长路径逻辑，后者让Windows API接受长路径。两个最好都设置，因为Git操作会同时涉及两者：git checkout需要Git本身支持，文件系统的实际写入需要Windows支持。

4.3 PowerShell的`\\?\`前缀技巧

PowerShell 5.1及之后版本，配合系统开启长路径，可以用\\?\前缀绕过某些限制。例如：

powershell复制Get-ChildItem -LiteralPath "\\?\C:\Very\Long\Path\Here"

\\?\前缀告诉Windows API跳过正常的路径规范化过程——不解析相对路径、不检查点号、不展开为完整路径，直接把后面的字符串当作字面绝对路径处理。这是Windows底层一直存在的能力，长路径开关本质上只是让更多的API调用默认获得类似行为，而\\?\是显式强制使用。

不过\\?\有个坑：它不识别正斜杠，必须用反斜杠，而且不能用于相对路径。在脚本里我一般只在程序自身不支持长路径时兜底使用。

4.4 WinRAR、7-Zip和压缩文件解压场景

7-Zip较新版本自身支持长路径，与系统设置无关。WinRAR从5.60版开始也支持长路径解压，但需要在设置里勾选启用长文件名或者Unicode文件名相关选项。如果你在Win11上解压一个深度嵌套的ZIP包，默认出问题，可以先换7-Zip试试。

5. 网络驱动器、映射盘符和Windows 11新版本的行为差异

5.1 映射网络驱动器与UNC路径

本地磁盘的长路径开关，对网络路径的影响是有限的。映射驱动器（比如Z:\指向一个NAS共享），实际访问时Windows会把它转换回UNC路径（\\server\share\...）。这个转换过程涉及MUP（Multiple UNC Provider）和网络重定向器，属性和本地NTFS不完全一样。

在SMB共享上启用长路径，需要两端配合：客户端开启Win32长路径，服务端也要允许。Windows Server 2016及之后的SMB协议已经支持长路径，老式NAS（基于Samba的）则要看Samba版本。

如果访问网络共享时遇到长路径问题，大部分时候就算开了注册表也没用，这是SMB协议层面的行为。能用\\?\UNC\server\share\...形式访问是较为可靠的兜底方案。

5.2 Windows 11不同版本之间的表现差异

Windows 11 22H2、23H2、24H2在长路径支持上，基础行为一致，但在文件资源管理器的具体实现上略有差异。23H2之后资源管理器引入了新的地址栏和标签页逻辑，对长路径的容忍度比22H2好一些。24H2及后续版本在部分UI操作中已经很少看到260字符截断的报错，但在命令行工具和传统对话框中问题依然存在。

开发环境选择系统版本时，我会优先考虑这些细节。比如做CI/CD流水线构建，构建机上的Windows Server版本配合长路径支持，所呈现的行为也会与桌面版有所不同。

5.3 云同步目录的额外限制

OneDrive、Dropbox这一类云同步工具，对路径长度有自己的限制。OneDrive要求路径总长度不超过400字符，这是其服务端的限制，跟Windows的260字符是两回事。你就算在Windows上开了长路径，OneDrive同步的目录依然可能触发其自身的阈值报错。所以做工程目录规划时，尽量把项目放在短的根目录下，比如C:\code\而不是C:\Users\你的用户名\OneDrive\Documents\...。

6. 自定义一个超长路径测试场景，快速验证功能是否生效

与其猜来猜去，不如直接构造一个长度超过260字符的目录结构来验证。PowerShell脚本如下：

powershell复制$base = "C:\longpathtest"
$path = $base
for ($i = 0; $i -lt 10; $i++) {
    $path = Join-Path $path ("dir" + $i.ToString().PadLeft(4, '0') + [string]::Join('', (1..10 | ForEach-Object { "x" })))
}
New-Item -ItemType Directory -Path $path -Force
$file = Join-Path $path ("file" + [string]::Join('', (1..80 | ForEach-Object { "y" })) + ".txt")
New-Item -ItemType File -Path $file -Force

看一下$file长度：

powershell复制$file.Length

如果输出了一个大于260的数字，且文件创建成功，说明文件系统层面已经支持长路径。如果报错，说明要么注册表没生效，要么PowerShell自身在尝试写入时走了截断逻辑。

这个脚本做验证很直观。我在排查"到底是不是系统限制"时，第一步永远是跑它，比在任何软件里反复试路径高效得多。

7. 梳理一些容易踩坑的杂项问题和操作建议

7.1 Windows Installer（MSI）是独立体系

即使注册表开了，Windows Installer服务也不会自动支持长路径。MSI安装包内部处理路径的方式主要取决于制作MSI的工具链。某些MSI在安装到长路径时会失败，这是安装包自身的问题。因此，安装程序时，建议安装到短路径（比如C:\Program Files\AppName），这与你是否开启长路径无关。

7.2 应用商店（MSIX）应用的路径策略

从Microsoft Store安装的MSIX应用，安装目标路径由系统管理，通常不会出现长路径问题。但如果用户数据被重定向到C:\Users\...\AppData\Local\Packages\...，这个路径本身就短不了，某些UWP/WinUI应用在导出数据或缓存时会触碰长路径边界。这种情况下，你在系统层面开启长路径有一定帮助，但并非所有API都会走Win32。

7.3 .NET Framework与.NET的差异

.NET Framework 4.6.1及以下版本，无论如何都不会支持长路径，需要在代码里用\\?\前缀手动处理，或者升级到4.6.2及以上版本。

.NET Core和.NET 5+则默认支持长路径，不需要在项目里额外配置——前提是运行环境Windows版本支持，且注册表开关已打开。

7.4 注册表开完没重启，等于白开

有的进程在注册表项修改后，会监听WM_SETTINGCHANGE消息动态更新，但Win32路径支持并不一定走这个机制。内核与API层面对该设置的读取，比如运行时缓存，往往要求整个进程重启。所以，修改完LongPathsEnabled后，即使不重启电脑，也要确保目标程序是全新启动的。

我见过有人在服务器上改完设置，IIS工作进程还在运行，结果显示长路径不生效，其实让应用池回收一次就好了。

7.5 关于"启用长路径会影响系统性能"的说法

有人担心开启长路径会降低系统性能。实际影响微乎其微，因为长路径支持只是改变了API对路径长度的检查阈值，字符串操作和路径解析的开销增加可以忽略不计。风险主要在于旧程序可能因为内部缓冲区不足而出现意外行为，而不是系统整体变慢。

建议在开发机或办公机上直接开启，但在生产服务器上，如果跑着大量古老的第三方程序，建议先评估测试再决定。

7.6 长路径关闭的注册表值

如果你想恢复默认（关闭），把LongPathsEnabled改回0，重启即可。这是个二进制开关，没有中间状态。

8. 我的最终建议：什么样的Windows 11环境适合开启长路径

结合我自己的使用经验，建议如下：

建议开启的场景：

开发机（Node.js、Python、Java、.NET都容易碰到深路径）
经常解压大压缩包或管理源码镜像的机器
使用Docker Desktop + WSL2做开发的机器（WSL2内部不受此限制，但文件互操作时Windows侧会受影响）

不建议轻易开启的场景：

医院、银行等运行大量老式C/S架构业务系统的终端
工控机，运行PLC编程软件、老驱动管理工具的
极在意稳定性的生产环境服务器

Win32长路径是Windows为自己过去的设计付出的一笔兼容性债务。开启它，意味着你选择让新型程序充分发挥能力，而不是为了让远古软件在2025年的系统上继续舒舒服服跑下去。

在Windows 11上完成这一步，对一个开发者来说，基本可以算做环境配置里的基础卫生措施。改完之后记得重启验证，顺手把git config --global core.longpaths true也设了，写代码能省很多事。