std::filesystem::exists() 是 c++17 起最直接可靠的文件/目录存在性判断方式，真实访问文件系统，但需注意权限、符号链接、路径合法性及跨平台差异。
用 std::filesystem::exists() 最直接可靠
C++17 起，std::filesystem::exists() 是判断文件或目录是否存在的标准方式，它会真实访问文件系统，不依赖路径语法猜测。注意它返回 false 时可能因为：路径不存在、无权限访问、或是符号链接指向无效目标（取决于实现和参数）。
实操建议：
- 必须包含头文件：
#include <filesystem></filesystem>，并链接-lstdc++fs（GCC 早期版本需显式链接，Clang 也类似） - 使用前建议先检查路径是否为有效格式：
std::filesystem::path p{"/tmp/test.txt"}; if (p.empty() || !p.is_absolute() && p.has_root_name())这类逻辑可提前过滤明显非法路径 - 若只需判断“可访问且存在”，不要仅靠
exists()后立刻open()—— 仍可能因竞态条件失败，生产代码应捕获std::filesystem::filesystem_error
access() 和 stat() 在 C++ 中仍常用但有陷阱
在嵌入式、旧项目或跨平台兼容性要求高时，常退回到 POSIX 函数：access()（检查权限）、stat()（获取元数据）。它们不经过 std::filesystem 抽象层，行为更底层但也更易出错。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
-
access(path, F_OK)在某些系统上对目录返回0却对文件返回 -1，只因当前用户无执行权限（Linux 下目录需 +x 才能access判定存在） -
stat()对符号链接默认解引用，想判断链接本身是否存在得用lstat() - Windows 下
access()不识别 UTF-8 路径（除非用_access_s()+ 宽字符 API），而std::filesystem默认处理编码转换
路径字符串本身合法性 ≠ 文件存在性
很多开发者误以为 std::filesystem::path 构造成功就代表路径“有效”，其实不然。例如 std::filesystem::path{".././sub//file.txt"} 合法，但对应磁盘位置可能根本不存在；又如 Windows 上 "CON"、"PRN" 是保留名，路径语法合法却永远无法创建对应文件。
使用场景提醒：
- 用户输入路径时，先用
p.lexically_normal()规范化，再用p.has_filename()和p.has_parent_path()检查结构合理性 - Windows 下需额外过滤设备名：
if (p.root_name().string() == "CON" || p.filename().string() == "AUX")—— 这类路径调exists()总是返回false，但不是因为“不存在”，而是系统禁止访问 - 空字符串、仅含空格、含控制字符的
std::string构造path会静默截断或抛异常，务必前置校验
跨平台判断时最易忽略的权限与挂载点问题
同一段 exists() 代码在 Linux 和 Windows 表现可能不同：Linux 下若路径位于未挂载的 NFS 分区，exists() 可能卡住数秒后才报错；Windows 下 NTFS 卷影副本或重定向文件夹（如 OneDrive）可能导致 exists() 返回 true，但实际读取时触发同步或权限弹窗。
性能与兼容性影响：
- 高频调用
exists()做轮询（如等待文件生成）极易引发 I/O 瓶颈，应改用 inotify / ReadDirectoryChangesW / 或异步监听 - 容器环境里，宿主机挂载的路径在容器内可能显示存在但不可读（SELinux 或 rootless podman 权限限制），此时
exists()+is_regular_file()都返回true，但fopen()失败 - 若项目需支持 C++14 或更低，别硬套
std::filesystem—— 用条件编译切到access()/GetFileAttributes()，并统一封装错误码映射
exists() 的返回值只是起点，不是结论。 
