Windows下CreateFile报ERROR_PATH_NOT_FOUND但路径存在，是因长路径超260字符触发MAX_PATH限制；需在绝对路径前加"?"前缀绕过检查，C++中std::filesystem亦需手动预处理，跨平台须条件编译封装。
Windows下CreateFile报错ERROR_PATH_NOT_FOUND但路径明明存在
这是典型的长路径（>260字符）触发Windows传统API限制。系统默认启用“MAX_PATH”限制，哪怕路径语法完全正确，CreateFile、OpenFile等Win32函数也会直接失败，错误码常是ERROR_PATH_NOT_FOUND或ERROR_INVALID_NAME，而非更直观的“路径太长”。
实操建议：
- 在路径字符串开头加
\\?\前缀（注意是4个反斜杠+1个问号+2个反斜杠），例如\\?\C:\very\long\path\...，此时Windows会绕过MAX_PATH检查，允许最多32767字符 - 该前缀仅对绝对路径有效，相对路径不支持；且不能包含
.或..向上遍历，必须是规范化的绝对路径 - 前缀只影响路径解析阶段，后续所有Win32 API（如
ReadFile、GetFileSize）都可正常工作，无需额外适配
C++标准库std::filesystem打开长路径失败
从C++17起，std::filesystem在Windows上默认仍走传统Win32路径处理逻辑，遇到超长路径会抛std::filesystem::filesystem_error，底层错误码仍是ERROR_PATH_NOT_FOUND。
实操建议：
- 手动预处理路径：用
std::filesystem::absolute(path)转为绝对路径，再拼接L"\\?\\" + absolute_path.native()（注意宽字符串） - 调用
std::filesystem::status或exists前，先确保路径已加\\?\前缀，否则检测必然失败 - 避免混用：不要把带
\\?\前缀的路径传给std::filesystem::path构造函数后直接用.string()取回——它会自动剥离前缀，导致后续操作再次失败
项目级启用长路径支持（注册表/组策略）是否可靠？
Windows 10 1607+ 提供全局开关LongPathsEnabled，设为1后部分API（如PowerShell、.NET Core）可自动处理长路径，但C++原生Win32调用**不自动受益**。
实操建议：
- 该开关对
CreateFile等底层API无效，它只影响Shell、cmd、某些高级语言运行时的路径规范化逻辑 - 即使开启，C++代码中仍需显式加
\\?\前缀，否则旧代码照常崩溃 - 企业环境慎用组策略强制开启——它会影响整个系统，而你的程序可能部署在未开启该选项的客户机器上，不可控
跨平台代码里怎么安全封装长路径处理？
Linux/macOS无此限制，硬加\\?\会导致路径非法。直接条件编译容易漏掉边界情况，比如路径拼接中途丢掉前缀。
实操建议：
- 写一个轻量包装函数，如
canonical_win_path(const std::wstring& path)，仅在_WIN32下做absolute + prefix，其他平台直返path - 所有文件操作入口（如
open_file、read_config）必须经过该函数，杜绝裸路径直传Win32 API - 特别注意第三方库调用：如libuv、Boost.Filesystem，查清它们是否内部处理了
\\?\——多数不会，仍需你前置转换
最麻烦的不是加前缀本身，而是路径在多层函数间传递时被意外转义、截断或重规范化。一旦某个中间环节调用了.generic_string()或.make_preferred()，\\?\就没了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
