_pathconf 返回 -1 表示无硬性路径长度上限，是 POSIX 合法行为；应以运行时 errno == ENAMETOOLONG 为判断依据，而非预设 MAX_PATH 或依赖 getconf。
为什么 _pathconf 返回 -1 而不是实际值
很多开发者调用 _pathconf 获取 _PC_PATH_MAX 时得到 -1，误以为系统不支持或函数失效。其实这是 POSIX 的合法返回——表示“没有硬性上限”，但不代表可以无限长。Linux 下多数文件系统（如 ext4、XFS）确实不限制路径总长，只限制单个组件（NAME_MAX）；而 Windows 子系统（WSL）或某些挂载的网络文件系统（NFS、CIFS）可能返回具体数值。
-
_pathconf("/", _PC_PATH_MAX)是最稳妥的调用方式，传入根目录避免因当前路径权限 / 挂载点导致失败 - 若返回 -1，不能直接 fallback 到
MAX_PATH（那是 Windows API 概念，C++ 标准库不定义它） - POSIX 环境下应结合
pathconf(".", _PC_NAME_MAX)和实际路径深度预估安全上限
MAX_PATH 在 C++ 中根本不可靠
MAX_PATH 是 Windows SDK 定义的宏（通常为 260），但它既不是 C++ 标准，也不反映现代 Windows 实际能力。启用了 long path support（通过 longPathAware = true 或注册表配置）后，NT 内核可处理超长路径，但 MAX_PATH 值不变。更关键的是：C++ 标准库（如 std::filesystem::path）完全不使用这个宏，它的内部路径拼接和解析逻辑基于运行时系统调用返回的实际限制。
- 不要在跨平台代码中 #ifdef WIN32 然后硬写
MAX_PATH作缓冲区大小 -
std::filesystem::path构造本身不会截断，但后续.string()或传给open()等系统调用时才可能失败 - 错误通常表现为
std::filesystem::filesystem_error，异常信息里含ENAMETOOLONG，这才是真实信号
真正该检查的其实是 ENAMETOOLONG 错误码
路径长度问题从来不是编译期或初始化时能静态确定的，而是运行时与具体文件系统、挂载选项、甚至当前进程的 chroot 状态强相关。最务实的做法是：先尝试操作，再根据 errno 处理。
- 对
open()、stat()、mkdir()等系统调用，检查errno == ENAMETOOLONG - 对
std::filesystem，捕获std::filesystem::filesystem_error并用.code().value() == ENAMETOOLONG判断 - 不要提前“预防性截断”路径——这反而可能破坏语义（比如把
/a/b/c/file.txt截成/a/b/c/fil……）
Linux 下 _pathconf 与 getconf 命令结果不一致怎么办
终端执行 getconf PATH_MAX / 可能返回 4096，而程序里 _pathconf("/", _PC_PATH_MAX) 返回 -1，这不是 bug。因为 getconf 是 shell 工具，它可能读取内核头文件定义、glibc 编译时配置，或 fallback 到某个保守值；而 _pathconf 是运行时系统调用，直连内核接口，更真实。
立即学习 “C++ 免费学习笔记（深入）”；
- 以
_pathconf运行时返回为准，getconf仅作参考 - 若需兼容性兜底，可用
sysconf(_SC_PATH_MAX)，它在多数 glibc 系统上行为更稳定 - 注意：
_SC_PATH_MAX和_PC_PATH_MAX参数不同，前者是全局系统配置，后者是路径相关配置，优先用后者
