Windows 默认的 260 字符路径限制（MAX_PATH）其实是个历史遗留的“约定”，并非系统 API 硬编码死锁。从 Windows 10 1607 版本开始，系统层面已经支持长路径，但想要真正绕过这个限制，得同时满足两个条件：一是使用 \\?\ 前缀加上绝对宽字符路径，二是在系统组策略或注册表中启用长路径支持。如果只满足其中一个，哪怕路径本身合法，像 CreateFileA、std::filesystem::exists 这类函数也会直接甩给你一个 ERROR_FILENAME_EXCED_RANGE（错误码 206）。
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，避免因父目录不存在导致\\?\路径被拒绝（\\?\不支持相对路径，也不展开..）
示例：
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:\\temp\\..\\foo不会被简化，可能因路径语义错误失败
为什么加了 \\?\ 还是报错 ERROR_PATH_NOT_FOUND
这个错误常被误判为“长路径没生效”，实际多数情况与前缀无关：
- 目标路径中某一级目录不存在（
\\?\不创建中间目录，CreateDirectoryW也需同样加前缀） - 使用了窄字符 API（
CreateFileA），\\?\前缀在窄字符串下会被当作普通路径字面量，失去特殊含义 - 路径含非法字符（如
<、|、?）且未转义——\\?\不豁免 NTFS 保留字符校验 - 程序未以管理员权限运行，而目标路径位于受保护位置（如
C:\\Windows子目录），此时即使路径合法也会被访问拒绝拦截
真正棘手的是：某些第三方库（如 Boost.Filesystem 旧版、Qt 5.x 的 QDir）内部硬编码了 MAX_PATH 缓冲区，即使你传入 \\?\ 路径，它们也会先用 GetFullPathNameW 做预处理并截断——这种问题只能换库或绕开封装直调 Win32。
