PATH_MAX不可靠，应动态调用pathconf()获取文件系统实际限制；Windows需用?前缀配合长路径支持；std::filesystem::path需手动预检长度。
Linux/macOS 下用 PATH_MAX 要小心，它不总是可靠
在 Linux 或 macOS 上，PATH_MAX 看起来是标准答案，但它其实是个“编译时假想值”——内核并不强制统一限制，不同文件系统甚至挂载点可能有不同上限。比如某些 tmpfs 或 NFS 挂载点实际支持的路径长度远小于 PATH_MAX（通常是 4096），而有些 ext4 分区可能允许更长。直接 #include <limits.h> 后用 PATH_MAX，在跨文件系统拼接路径或调用 realpath() 时容易触发 ENAMETOOLONG。
- 真正安全的做法是：用
pathconf(path, _PC_PATH_MAX)动态查当前目录所在文件系统的限制 - 如果传入的
path不存在，得 fallback 到父目录（比如用dirname()反复上溯，直到access()成功） - 注意
pathconf()返回 -1 表示不支持该查询，此时才考虑用PATH_MAX作保守兜底
Windows 下必须用 MAX_PATH 和长路径前缀双保险
Windows 默认 MAX_PATH 是 260，但启用长路径支持后，API 实际可处理 32767 字符——前提是路径带 \? 前缀且程序 manifest 正确声明。只定义 MAX_PATH 宏（来自 windows.h）完全没用，因为 Win32 API 在内部仍会截断或拒绝不带前缀的超长路径。
- 检查是否启用长路径：读注册表
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled，值为 1 才有效 - 所有路径操作（
CreateFileW、GetFullPathNameW等）必须用宽字符 +\?前缀，例如L"\\?\C:\very\long\path" - 不要用
_MAX_PATH（来自stdlib.h），那是 CRT 的旧约束，和系统 API 不一致
getconf PATH_MAX / 和 C++ 运行时行为不一致
终端里跑 getconf PATH_MAX / 输出的数字，和你在 C++ 里调 pathconf("/", _PC_PATH_MAX) 返回的值经常不一样。前者是 shell 或 libc 编译时的静态配置，后者才是运行时内核返回的真实限制。尤其在容器环境（如 Docker）中，getconf 可能读的是宿主机头文件，而 pathconf() 访问的是容器挂载的 proc/sysfs，结果偏差可达数倍。
- 写可移植代码时，永远以
pathconf()返回值为准，别信文档或命令行工具 - 在
chroot或 namespace 隔离环境中，pathconf()会自动适配当前 root 的挂载点限制 - 如果
pathconf()失败（errno =EINVAL），说明该路径不支持查询，此时应按最小安全值（如 4096）分配缓冲区
std::filesystem::path 没有内置最大长度检查，得自己兜底
C++17 的 std::filesystem::path 对路径长度完全放任，构造、拼接、string() 转换都不会报错，直到你调 exists() 或 canonical() 才可能因系统调用失败抛出 std::filesystem::filesystem_error，错误码却是 std::errc::filename_too_long —— 这个时机太晚，不利于提前校验。
立即学习“C++免费学习笔记（深入）”；
- 建议封装一个
safe_path_length(const std::filesystem::path& p)函数，内部调用pathconf(p.c_str(), _PC_PATH_MAX)（POSIX）或GetVolumeInformationW()（Windows） - 对用户输入的路径，在构建
std::filesystem::path前就做长度预检，避免后续操作意外失败 - 注意
std::filesystem::path::generic_string()返回的格式可能不含驱动器号或 UNC 前缀，Windows 下需手动补全再查限制
PATH_MAX 的语义根本不在一个层面上。 
