MAX_PATH 是 Windows SDK 中定义的编译期宏常量（#define MAX_PATH 260），表示传统 Win32 路径 API 支持的最大空终止字符串长度（含驱动器、冒号、反斜杠和末尾 ），非运行时可查询值。
Windows 上 MAX_PATH 是编译期常量，不是运行时可查值
在 Windows 的 C++ 开发中，MAX_PATH 并非由系统动态返回的运行时能力上限，而是 Windows SDK 头文件（如 windef.h）里定义的宏：#define MAX_PATH 260。它代表传统 Win32 路径 API（如 CreateFileA、FindFirstFileW）默认接受的**最大空终止字符串长度（含驱动器盘符、冒号、反斜杠和末尾 ）**。
这意味着：
- 你无法通过某个 C++ 标准库函数（如
std::filesystem::path::max_size()）“获取”它——它根本不在运行时暴露 sizeof("C:\some\path") 这类判断，依赖的是你包含头文件后预处理器展开的字面值- 即使你调用
GetFullPathNameW或GetCurrentDirectoryW，它们仍受MAX_PATH缓冲区限制，除非你显式启用长路径支持
如何让程序真正突破 MAX_PATH 限制（Windows 10+）
突破 260 字符限制的关键不是“查最大值”，而是**启用长路径支持并使用 Unicode API + \? 前缀**。否则，哪怕系统允许，Win32 API 仍会截断或报错 ERROR_FILENAME_EXCED_RANGE。
必须同时满足以下条件：
立即学习“C++免费学习笔记（深入）”；
- 目标 Windows 版本 ≥ 10 1607（Anniversary Update）
- 注册表项
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled值为1（管理员权限修改） - 你的程序 manifest 文件中声明
longPathAware="true"（否则即使注册表开启，应用仍被沙箱限制） - 调用 API 时使用宽字符版本（
W后缀），且对绝对路径加L"\\?\C:\..."前缀（注意是四个反斜杠）
例如打开超长路径文件：
HANDLE h = CreateFileW(L"\\?\C:\very\long\path\...",
GENERIC_READ, 0, nullptr, OPEN_EXISTING, 0, nullptr);
std::filesystem::path::max_size() 返回什么？别误用
C++17 的 std::filesystem 并不返回操作系统级路径长度上限。它的 max_size() 是该实现内部 path 对象能容纳的字符数（通常远大于 260，比如 1024 或 4096），仅反映容器容量，与 Win32 路径解析逻辑无关。
实测行为：
- 即使
path.max_size() == 4096，若未启用长路径支持，std::filesystem::exists(p)对超过 260 字符的路径仍可能返回false（且不抛异常，errno可能为ERROR_FILENAME_EXCED_RANGE） - 它不检查
\?前缀，也不自动添加——你需要自己构造合法长路径字符串再传入 - 跨平台代码中更不可靠：Linux/macOS 下该值无意义，
PATH_MAX才是 POSIX 系统的实际限制（需#include <limits.h>）
Linux/macOS 怎么查 PATH_MAX？用 pathconf() 而非宏
POSIX 系统（Linux/macOS）的路径长度上限不是编译期固定值，而取决于文件系统。标准做法是调用 pathconf() 查询当前挂载点的实际限制：
long max_path = pathconf("/home", _PC_PATH_MAX);
if (max_path == -1) {
// 错误处理，如 errno == EINVAL 表示不支持查询
}
注意：
-
PATH_MAX宏（来自<limits.h>）只是“最小保证值”（Linux 通常是 4096），实际可能更大（如 XFS 支持 1024*1024） - 必须传入一个**真实存在的路径**（如
"/"或"."），不能传空字符串或非法路径 - 不同挂载点可能返回不同值（例如
/tmp在 tmpfs 上，/home在 ext4 上）
真正难的从来不是“查数字”，而是路径拼接、规范化、API 选型时是否全程考虑边界——尤其当 \? 前缀漏加、manifest 缺失、或 pathconf 返回 -1 却没兜底时，问题才开始浮现。
