我在不合时宜的时刻遇到了几次这个问题：
- 尝试在具有深层路径的开源Java项目上工作
- 在源代码管理中存储Deep Fitnesse Wiki树
- 尝试使用Bazaar导入我的源代码管理树时出错
为什么存在此限制？
为什么还没有删除它？
您如何应对路径限制？ ...并且不，切换到linux或Mac OS X并不是此问题的有效答案;）
#1楼
引用本文https://docs.microsoft.com/zh-cn/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation
最大路径长度限制
在Windows API（以下段落讨论了一些例外）中，路径的最大长度为MAX_PATH ，它定义为260个字符。 本地路径按以下顺序构造：驱动器号，冒号，反斜杠，用反斜杠分隔的名称组件以及终止的空字符。 <NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. 例如，驱动器D上的最大路径是“ D：\\ <NUL>”，其中“ <NUL>”代表当前系统代码页的不可见终止空字符。 （此处使用字符<>是为了清晰起见，并且不能成为有效路径字符串的一部分。）
现在我们看到它是1 + 2 + 256 + 1或[drive] [：\\] [path] [null] =260。从DOS天开始，我们可以假定256是合理的固定字符串长度。 回到DOS API，我们意识到系统跟踪每个驱动器的当前路径，并且我们有26个驱动器 （和32个带符号的）最大驱动器 （和当前目录）。
INT 0x21 AH = 0x47表示“此函数返回的路径描述中不包含驱动器号和初始反斜杠。”因此，我们看到系统将CWD存储为一对（驱动器，路径），并且您通过指定驱动器（1 = A，2 = B，…），如果您指定0，则假定INT 0x21 AH = 0x15 AL = 0x19返回的驱动器路径。 现在我们知道为什么是260，而不是256，因为这4个字节没有存储在路径字符串中。
为什么要使用256字节的路径字符串，因为640K足够的RAM。
#2楼
由于NTFS文件系统最多支持32k个字符的路径，因此这并非严格如此。 您可以使用win32 api和“ \\\\?\\ ”作为路径前缀，以使用超过260个字符。
.Net BCL团队博客的详细解释。
一小段摘录突出了长途问题
另一个令人担忧的问题是，由于暴露长途支持而导致的行为不一致。 带有
\\\\?\\前缀的长路径可以在大多数与文件相关的Windows API中使用，但不能在所有Windows API中使用。 例如，如果文件名长于MAX_PATH，则将模块映射到调用进程地址的LoadLibrary失败。 因此，这意味着MoveFile将使您可以将DLL移到其路径长于260个字符的位置，但是当您尝试加载DLL时，它将失败。 整个Windows API中都有类似的示例。 存在一些变通办法，但它们是逐案的。
#3楼
您可以将文件夹安装为驱动器。 在命令行中，如果您具有路径C:\\path\\to\\long\\folder ，则可以使用以下命令将其映射到驱动器号X: :：
subst x: \path\to\long\folder
#4楼
解决路径限制的一种方法是缩短具有符号链接的路径条目。
例如：
- 创建一个
C:\\p目录，以保留指向长路径的短链接 -
mklink /JC:\\p\\foo C:\\Some\\Crazy\\Long\\Path\\foo - 将
C:\\p\\foo添加到您的路径而不是长路径
#5楼
至于为什么它仍然存在-MS并不认为它是优先事项，并且重视向后兼容性而不是升级其OS（至少在这种情况下）。
我使用的一种解决方法是对路径中的目录使用“短名称”，而不是其标准的，人类可读的版本。 因此， 例如对于C:\\Program Files\\我将使用C:\\PROGRA~1\\您可以使用dir /x找到等效的短名称。
来源：oschina
链接：https://my.oschina.net/stackoom/blog/3166860