Windows下CreateFileW超长路径失败的直接原因是系统默认限制，需同时满足注册表启用、清单声明及路径以L"\?C:"开头；std::filesystem::exists会静默返回false，应手动拼接前缀并用GetFileAttributesW验证。
Windows下CreateFileW调用超长路径失败的直接原因
不是代码写错了，是系统默认拦住了。Windows传统API对路径长度硬性截断在MAX_PATH（260字符），哪怕路径语法完全合法，CreateFileW也会返回ERROR_PATH_NOT_FOUND或ERROR_INVALID_NAME——它根本没走到文件系统层，就在路径解析阶段被拒了。
关键不在“怎么拼字符串”，而在“让系统允许你传这么长的路径”。必须同时满足三件事：
- 系统注册表
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled值为1（Win10 1607+才有效） - 你的可执行文件manifest中声明
<longPathAware>true</longPathAware>（VS里勾选“启用长路径支持”即可） - 调用时路径必须是宽字符绝对路径，且以
L"\?\C:\..."开头（注意：4个反斜杠+问号+驱动器）
std::filesystem::exists对超长路径静默返回false的坑
std::filesystem::exists(p)不报异常、不设errno，就默默返回false，你以为路径不存在，其实只是被MAX_PATH截断了。这是因为std::filesystem底层仍走Win32 API，没启用长路径支持时，它连\?前缀都自动剥离。
正确做法不是靠猜，而是主动构造合规路径：
立即学习“C++免费学习笔记（深入）”；
- 先用
std::filesystem::absolute(p)转成绝对路径 - 再拼接
L"\?\" + abs_path.native()（必须用.native()，不能用.string()） - 之后所有操作——
exists、status、open——都用这个带前缀的std::wstring，别再塞回std::filesystem::path对象里 - 验证是否生效：调用
GetFileAttributesW(long_path.c_str())，返回非INVALID_FILE_ATTRIBUTES即表示内核已就绪
UNC路径和网络共享的长路径写法差异
本地盘路径加?C:...能过，但网络路径写成?servershare...会失败——Windows要求UNC路径必须用?UNCservershare...格式，少一个UNC就识别不了。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
常见错误写法：
-
"\\?\server\share\..."❌ 缺UNC前缀 -
"\\?\UNC\server/share/..."❌ 混用正斜杠 -
"\\?\UNC\server\share\..\foo"❌\?下禁止..回退
实操建议：先用WNetGetUniversalName或GetFinalPathNameByHandle把映射网络驱动器转成真实UNC路径，再手动拼L"\?\UNC\"前缀。
跨平台项目里如何安全封装长路径逻辑
Linux/macOS没有MAX_PATH限制，但硬加\?前缀会导致std::filesystem::path解析失败。不能全局开开关，得按平台条件编译。
推荐结构：
- Windows平台：所有路径入口函数统一做
make_long_path(std::filesystem::path p)，内部判断是否绝对、是否已含\?，再补前缀 - 非Windows平台：直接返回
p.native() - 避免在
std::filesystem::path构造时传入带\?的字符串——它会当成普通路径组件处理，后续.string()又丢掉前缀 - 调试时打印原始
std::wstring长度，别信IDE变量窗口显示的截断内容
最麻烦的不是第一次构造，而是路径在函数间传递时被无意转回std::string或std::filesystem::path——只要中间任何一环丢了\?前缀，后面全挂。
