Windows长路径限制本质是历史遗留的用户态约定，并非API硬编码；自Win10 1607起需同时满足启用系统长路径支持（组策略/注册表）和使用\?前缀的绝对宽字符路径，才能绕过260字符限制。
Windows长路径限制的本质是什么
Windows默认的260字符路径限制（MAX_PATH）不是API硬编码，而是历史遗留的用户态约定。从Windows 10 1607起，系统已支持长路径，但需两个前提同时满足：\?前缀 + 系统组策略/注册表启用。否则哪怕路径本身合法，CreateFileA、std::filesystem::exists等都会直接返回ERROR_FILENAME_EXCED_RANGE（错误码206）。
关键点在于：C++标准库（如std::filesystem）在MSVC实现中默认不自动加\?，它走的是普通Win32路径解析逻辑；而原生Win32 API只要传入带\?的宽字符路径（L"\\?\C:\..."），就能绕过260限制——前提是目标目录存在且权限足够。
用std::filesystem安全处理长路径的实操方式
MSVC 19.29+（VS 2019 16.11+）开始，std::filesystem对长路径的支持仍依赖运行时是否开启全局长路径支持，不能仅靠加前缀。实际使用中建议：
- 编译前确认项目启用Unicode（
_UNICODE和UNICODE宏已定义），所有路径操作必须用std::wstring或std::filesystem::path宽字符构造
- 手动拼接
\?前缀时，必须用std::filesystem::path(L"\\?\") / L"C:\very\long\path"，不能用+或string()转窄字符串——后者会触发内部窄路径截断
- 调用前检查
std::filesystem::status(path).type() != std::filesystem::file_type::not_found，避免因父目录不存在导致\?路径被拒绝（\?不支持相对路径，也不展开..）
_UNICODE和UNICODE宏已定义），所有路径操作必须用std::wstring或std::filesystem::path宽字符构造\?前缀时，必须用std::filesystem::path(L"\\?\") / L"C:\very\long\path"，不能用+或string()转窄字符串——后者会触发内部窄路径截断std::filesystem::status(path).type() != std::filesystem::file_type::not_found，避免因父目录不存在导致\?路径被拒绝（\?不支持相对路径，也不展开..）示例：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::filesystem::path p = std::filesystem::path(L"\\?\") / L"C:\Users\a\b\c\...\deep\file.txt";
if (std::filesystem::exists(p)) {
auto f = std::ifstream(p, std::ios::binary);
}
Win32 API层面绕过限制的必要条件
直接调用CreateFileW、FindFirstFileW等函数时，\?前缀是唯一可靠方式，但有严格格式要求：
- 前缀必须是
L"\\?\\"（4个反斜杠+1个冒号+1个反斜杠），开头两个反斜杠是字面量，后两个构成UNC风格根标识
- 路径必须为绝对路径，不能含
.、..、/，也不能是相对驱动器路径（如L"\\?\D:file.txt"非法，必须是L"\\?\D:\file.txt"）
- 若操作网络路径，须用
\\?\UNC\server\share而非\\?\\server\share——少一个U就失败
- 注意
\?路径跳过Windows路径规范化，意味着\?C: emp.. oo不会被简化，可能因路径语义错误失败
为什么加了\?还是报错 ERROR_PATH_NOT_FOUND
这个错误常被误判为“长路径没生效”，实际多数情况与前缀无关：
- 目标路径中某一级目录不存在（
\?不创建中间目录，CreateDirectoryW也需同样加前缀）
- 使用了窄字符API（
CreateFileA），\?前缀在窄字符串下会被当作普通路径字面量，失去特殊含义
- 路径含非法字符（如
<、|、?）且未转义——\?不豁免NTFS保留字符校验
- 程序未以管理员权限运行，而目标路径位于受保护位置（如
C:Windows子目录），此时即使路径合法也会被访问拒绝拦截
L"\\?\\"（4个反斜杠+1个冒号+1个反斜杠），开头两个反斜杠是字面量，后两个构成UNC风格根标识.、..、/，也不能是相对驱动器路径（如L"\\?\D:file.txt"非法，必须是L"\\?\D:\file.txt"）\\?\UNC\server\share而非\\?\\server\share——少一个U就失败\?路径跳过Windows路径规范化，意味着\?C: emp.. oo不会被简化，可能因路径语义错误失败\?还是报错 ERROR_PATH_NOT_FOUND
这个错误常被误判为“长路径没生效”，实际多数情况与前缀无关：
- 目标路径中某一级目录不存在（
\?不创建中间目录，CreateDirectoryW也需同样加前缀） - 使用了窄字符API（
CreateFileA），\?前缀在窄字符串下会被当作普通路径字面量，失去特殊含义 - 路径含非法字符（如
<、|、?）且未转义——\?不豁免NTFS保留字符校验 - 程序未以管理员权限运行，而目标路径位于受保护位置（如
C:Windows子目录），此时即使路径合法也会被访问拒绝拦截
真正棘手的是：某些第三方库（如Boost.Filesystem旧版、Qt 5.x的QDir）内部硬编码了MAX_PATH缓冲区，即使你传入\?路径，它们也会先用GetFullPathNameW做预处理并截断——这种问题只能换库或绕开封装直调Win32。
