getvolumeinformation 返回的 lpmaximumcomponentlength 是卷级单个文件名最大长度（如 ntfs 为 255），非全路径限制；需结合 max_path 或 long path 支持状态判断完整路径可行性，且不可与 posix 的 path_max/name_max 混用。
Windows 下用 GetVolumeInformation 查 lpMaximumComponentLength
Windows 不像 Unix 系统有统一的 PATH_MAX，而是按卷（volume）分别定义路径组件最大长度（即单个文件名或目录名长度），这个值由文件系统决定。调用 GetVolumeInformation 是最直接的方式，它返回的 lpMaximumComponentLength 参数就是该卷支持的最大文件名长度（不含路径分隔符和驱动器前缀）。
常见误区是以为它返回的是完整路径长度上限——其实不是。Windows 全路径长度限制（MAX_PATH = 260）是另一层约束，且从 Windows 10 1607 起可通过启用 long path support 绕过，但 GetVolumeInformation 返回的仍是底层文件系统原生限制（如 NTFS 通常为 255，ReFS 为 32767）。
实操建议：
- 传入当前路径所在卷的根目录（如
"C:\"），而非任意路径；否则可能因跨卷失败 - 检查返回值：函数失败时返回 0，需用
GetLastError()判断原因（如路径不存在、无访问权限） - 若只需组件长度（如校验文件名是否合法），用这个值即可；若要判断完整路径能否被系统接受，还得叠加 MAX_PATH 或 long path 启用状态
Linux/macOS 下查 PATH_MAX 和 NAME_MAX
POSIX 系统用两个宏区分限制：PATH_MAX 是路径总长度上限（含终止符），NAME_MAX 是单个目录项（文件名）最大长度。它们不是编译期常量，部分系统上 PATH_MAX 甚至未定义（如某些嵌入式 glibc 或 musl），必须运行时查询。
正确做法是调用 pathconf()：
-
pathconf(".", _PC_PATH_MAX)获取当前目录所在文件系统的路径长度上限；若返回 -1 表示无硬性限制（如某些 Linux 文件系统支持动态分配） -
pathconf(".", _PC_NAME_MAX)获取该文件系统单个文件名最大字节数（注意：是字节数，非字符数；UTF-8 多字节字符会占多个字节） - 不要直接用
limits.h中的PATH_MAX宏——它只是编译器提供的建议值，实际文件系统可能更小或更大 - macOS 上
_PC_PATH_MAX常返回 -1，此时应保守采用 1024 或 4096 作为安全上限，或改用realpath()+ 错误反馈试探
C++ 跨平台封装要注意的三个细节
写一个跨平台函数获取“可用路径长度上限”时，不能简单取最大值或硬编码。关键点在于目标用途不同，所需值也不同：
- 若用于路径拼接前的长度预检（如避免
std::filesystem::path构造失败），应优先用文件系统原生NAME_MAX/lpMaximumComponentLength，因为std::filesystem在构造时就可能因组件过长抛std::filesystem::filesystem_error - 若用于生成临时文件并确保
open()成功，则还要考虑内核级限制（如 Linux 的AT_FDCWD路径解析深度、namei 层缓冲区大小），这时pathconf()更可靠 - Windows 上启用 long path（通过 manifest 或组策略）后，
CreateFileW可处理 >260 字符路径，但GetVolumeInformation返回值不变——这意味着组件长度限制仍存在，只是总路径可更长；跨平台代码里别把二者混为一谈
容易被忽略的 std::filesystem 行为差异
std::filesystem 的 path 类本身不限制长度，但其操作函数（如 exists()、create_directories()）在底层调用 OS API 时会触发真实限制。尤其要注意：
- Windows MSVC 工具链下，即使启用了 long path，若未在 manifest 中声明
longPathAware=true，std::filesystem仍可能静默截断或抛出系统错误码 206（ERROR_FILENAME_EXCED_RANGE） - Linux 下
std::filesystem::path存储的是std::string，理论上无长度限制，但调用.c_str()后传给stat()等 C API 时，若路径超PATH_MAX，某些内核版本会返回ENAMETOOLONG - macOS 的
std::filesystem实现基于libcpp，对长路径兼容性较差；实测在 10.15+ 上超过 1024 字节的路径易导致std::filesystem::status()返回file_status(file_type::not_found)而非报错
真正棘手的不是“怎么查”，而是查完之后怎么用——同一段路径，在构造 path 对象、调用 exists()、传给 fopen() 时，可能在不同环节因不同限制失败。得按具体操作选对应约束值，而不是找一个“全局最大值”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
