MAX_PATH是Windows SDK中定义为260的编译期常量，不随长路径支持动态变化；实际路径长度限制取决于LongPathsEnabled注册表项与进程清单配置是否同时启用。
Windows 下 MAX_PATH 是编译期常量，不是运行时可查值
很多人以为 MAX_PATH 是系统动态决定的，其实它在 Windows SDK 中定义为 260（#define MAX_PATH 260），是纯编译期常量。它不反映当前系统实际支持的路径长度上限，也不随启用长路径支持（LongPathsEnabled）而改变。
真正影响运行时行为的是注册表项和进程清单配置：
-
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled == 1（全局开关） - 可执行文件 manifest 中包含
<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowssettings><longpathaware>true</longpathaware></windowssettings></application>
只有两者同时满足，CreateFileW、FindFirstFileW 等宽字符 API 才能处理超过 260 字符的路径；否则仍受 MAX_PATH 截断限制。
如何判断当前进程是否启用长路径支持
没有标准 C++ API 直接返回“当前支持的最大路径长度”，但可通过检查进程是否具备长路径能力来间接推断：若已启用，则理论无硬限制（仅受内存与 NTFS 限制，约 32767 字符）；否则严格受限于 MAX_PATH。
立即学习“C++免费学习笔记（深入）”；
推荐用以下方式检测：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 调用
GetVersionEx或VerifyVersionInfo确保系统为 Win10 1607+（长路径支持起始版本） - 读取注册表
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled值（需管理员权限读 HKLM，也可尝试 HKCU fallback） - 更可靠的做法：尝试用
\?前缀构造一个 >260 字符的合法路径（如L"\\?\C:\..."），再调用GetFileAttributesW。成功返回非INVALID_FILE_ATTRIBUTES即说明内核层已就绪
std::filesystem::path::max_size() 不是你要找的系统路径长度限制
这个成员函数返回的是 std::filesystem::path 对象内部缓冲区的容量（通常是实现相关，常见为 4096），和操作系统路径长度限制完全无关。它既不读取注册表，也不检查 manifest，更不反映 MAX_PATH 或长路径状态。
误用示例：
std::cout << std::filesystem::path::max_size() << " "; // 输出可能是 4096 —— 毫无系统参考价值
它只说明该 path 实例最多能存多少字符，不能用于路径合法性校验或截断决策。
实战建议：路径长度校验应分场景处理
不要试图“获取最大长度”后统一截断。真实项目中应按用途区别对待：
- 普通文件 I/O（
fopen,std::ifstream）：默认走 ANSI/short-path 路径解析，必须 ≤MAX_PATH，且不能含\? - Win32 宽字符 API（
CreateFileW）：启用长路径后可传入\?前缀路径，此时长度上限由内核和磁盘格式决定，无需硬编码上限值 - 跨平台代码：优先用
std::filesystem，但它底层在 Windows 上仍可能降级到短路径逻辑（取决于编译器和 CRT 版本），不能假设自动支持长路径
最稳妥的校验方式是——直接试操作。比如创建前先 GetFileAttributesW(path.c_str()) == INVALID_FILE_ATTRIBUTES 且 GetLastError() == ERROR_PATH_NOT_FOUND，再结合路径长度 > 260 判断是否需加 \? 前缀重试。
别忘了：即使系统支持长路径，某些旧版 CRT 函数（如 _stat）或第三方库仍会内部截断到 MAX_PATH，这种限制只能靠替换 API 或绕过处理。
