_pathconf 返回 -1 通常因路径非法：须为真实存在的绝对目录路径，非空字符串、相对路径或不存在路径；errno 可区分 EINVAL、ENOENT、EACCES 等错误原因。
为什么 _pathconf 返回 -1 或报错？
调用 _pathconf 获取 _PC_NAME_MAX 时返回 -1，通常不是函数失败，而是你传入的路径参数不合法。它不接受空字符串、相对路径（如 "."）、或当前不存在的目录路径——必须是**一个真实存在的、可访问的目录的绝对路径**。
- 正确做法：先用
getcwd拿到当前工作目录绝对路径，再传给_pathconf - 错误示例：
_pathconf(".", _PC_NAME_MAX)在某些系统（如 macOS）上会失败；_pathconf("/tmp/xxx", _PC_NAME_MAX)中/tmp/xxx不存在也会返回 -1 - 注意 errno：返回 -1 时检查
errno，若为EINVAL是参数非法，ENOENT是路径不存在，EACCES是权限不足
_pathconf 和 PATH_MAX 的区别在哪？
_pathconf(path, _PC_NAME_MAX) 返回的是该 path 所在文件系统对单个文件名（不含路径）的最大长度限制；而 PATH_MAX（通常定义在 <limits.h></limits.h>）是路径字符串整体（含所有目录分隔符）的最大字节数，两者语义完全不同，不能混用。
-
_PC_NAME_MAX常见值：Linux ext4 一般为 255，XFS 可达 255，macOS APFS 是 255，Windows Subsystem for Linux（WSL）取决于底层文件系统 -
PATH_MAX是编译期常量，Linux 上通常是 4096，但实际运行时可能受getconf PATH_MAX /影响；它和文件系统无关，更多约束的是系统调用参数长度 - 误用后果：用
PATH_MAX去截断文件名会导致在长路径下意外截断，比如"/a/b/c/" + filename拼接后超限
跨平台获取文件名长度上限的稳妥写法
Linux/macOS 支持 _pathconf，但 Windows MinGW/MSVC 不支持；直接硬编码 255 风险大（某些网络文件系统或容器卷可能更小），所以得 fallback。
- 优先调用
_pathconf，路径用getcwd(nullptr, 0)动态获取绝对路径 - 失败时 fallback 到
NAME_MAX（POSIX 定义的宏，需#include <limits.h></limits.h>），但注意它只是“典型值”，非运行时保证 - Windows 下可用
GetVolumeInformation查lpMaximumComponentLength，但 C++ 跨平台项目建议统一走std::filesystem::path的构造+filename().string().length()校验逻辑，而非预设上限 - 示例关键片段：
char* cwd = getcwd(nullptr, 0);<br>long name_max = (cwd != nullptr) ? _pathconf(cwd, _PC_NAME_MAX) : -1;<br>free(cwd);<br>if (name_max == -1) name_max = NAME_MAX;
别忽略文件系统差异带来的运行时变化
同一个程序，在挂载了不同文件系统的目录下运行，_pathconf(..., _PC_NAME_MAX) 返回值可能不同——比如你在 ext4 分区上开发，测试通过，但用户把程序部署在 NFS 或 FAT32 挂载点上，文件名限制可能骤降到 255 甚至 8.3。
立即学习“C++免费学习笔记（深入）”；
- 不要在初始化时只查一次就缓存结果；如果程序会长期运行且工作目录可能切换（如 chdir），每次操作前都应重新查
- 尤其注意容器环境：Docker 默认使用 overlay2，
_PC_NAME_MAX返回的是 overlay2 的限制（通常是 255），但底层存储可能是 XFS 或 ext4，实际能力被 overlay 层截断 - 最保险的做法：在关键路径（如保存用户上传文件）做运行时校验——生成文件名后，先
std::filesystem::path::filename()提取，再比较长度，超限时主动截断或报错，而不是依赖预查
事情说清了就结束
