应动态查询运行时路径长度限制：Linux/macOS调用pathconf(path, _PC_PATH_MAX)，Windows调用GetVolumeInformation获取max_path_len，std::filesystem不提供该接口，需绕过抽象层直接调用系统API。
Linux/macOS 下用 PATH_MAX 不一定靠谱
很多 C++ 代码直接写 char buf[PATH_MAX]，但 PATH_MAX 是编译时宏，不是运行时保证值。它可能未定义（比如 glibc 中某些配置下被禁用），也可能只是“典型值”，实际文件系统允许更长路径（如 ext4 支持远超 4096 字节的路径）。真正安全的做法是查运行时限制。
- 先调用
pathconf(path, _PC_PATH_MAX)，传入一个已存在的目录路径（如"/"或"."） - 若返回 -1，说明该文件系统不提供硬限制，此时可回退到
MAXPATHLEN（BSD 系统）或保守取 4096 - 注意：
pathconf返回的是路径总长度上限（含结尾'\0'），不是纯字符数
Windows 下必须用 GetVolumeInformation
Windows 没有统一的全局路径长度限制，实际取决于卷的文件系统（NTFS/FAT32）和是否启用长路径支持（Windows 10 1607+）。不能依赖 MAX_PATH（260）这个过时常量。
- 调用
GetVolumeInformation(L".", nullptr, 0, nullptr, &max_component_len, &max_path_len, nullptr, 0) - 关注返回的
max_path_len—— 这是该卷上单个路径字符串的最大字节数（UTF-16 编码，所以是wchar_t数） - 若程序 manifest 声明支持长路径，且系统开启策略，
max_path_len可达 32767；否则仍受 260 限制
std::filesystem::path 本身不提供长度限制接口
C++17 的 std::filesystem 是跨平台抽象层，设计上不暴露底层路径长度限制。它会在内部调用系统 API 做路径拼接和验证，但不会告诉你“最多还能加几个字符”。想预判截断或溢出，必须绕过它查原生 API。
- 不要试图用
path.string().size()判断是否超限——这只能反映当前字符串长度，不是系统允许上限 - 构建深层嵌套路径前，先用对应平台的
pathconf或GetVolumeInformation查目标目录所在卷的限制 - 尤其注意符号链接：真实路径长度可能因解析后暴涨，
pathconf对 symlink 目标路径才有效
跨平台封装建议：避免宏、优先查运行时
别写 #ifdef _WIN32 + #ifdef __linux__ 大段分支。用函数封装，让逻辑集中、测试可控。
- 写一个
get_max_path_length(const std::string& base_dir = ".")函数，内部按平台分发 - Linux/macOS 路径传
base_dir.c_str()给pathconf；Windows 用MultiByteToWideChar转成LPCWSTR再调GetVolumeInformation - 返回
size_t，失败时返回 0（调用方需检查） - 测试时故意挂载一个 tmpfs 并设小
path_max（Linux）或格式化 FAT32 U盘（Windows），比只跑在默认 NTFS 上更能暴露问题
实际路径长度边界永远绑定在「具体卷」和「当前内核/系统策略」上，不是语言或标准库能打包承诺的。每次操作前动态查，比记住一个数字可靠得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
