应优先使用 std::filesystem::exists() 判断文件存在性，它跨平台、语义清晰且能区分类型；注意权限不足或悬空符号链接会导致返回 false，需结合 is_symlink() 等进一步判断。
用 std::filesystem::exists() 最直接可靠
这是 C++17 引入的标准方案，跨平台、语义清晰，且能区分文件、目录、符号链接等类型。只要编译器支持 C++17（如 GCC 8+、Clang 7+、MSVC 2017 Update 3+），就应优先使用它。
注意：需链接 std::filesystem 库（GCC/Clang 加 -lstdc++fs，MSVC 默认启用）；Windows 上某些旧版 MSVC 需定义 _HAS_FILESYSTEMS=1。
示例：
#includenamespace fs = std::filesystem; if (fs::exists("config.json")) { // 文件存在（且可访问） }
常见误判点：
立即学习“C++免费学习笔记（深入）”；
-
fs::exists()返回false不一定代表路径不存在——可能是权限不足（如 Linux 下对父目录无执行权限），此时会抛出std::filesystem::filesystem_error - 若路径是悬空符号链接，
exists()返回false；用fs::is_symlink()+fs::symlink_status()可进一步判断
用 fopen() 或 access() 兼容老标准（C++98/03）
当无法使用 C++17 时，常用 C 风格函数兜底。但二者行为差异明显，选错容易埋坑。
fopen("path", "r") 尝试以只读方式打开，成功即认为“存在且可读”；access("path", F_OK)（POSIX）或 _access("path", 0)（Windows）仅检查路径是否存在，不验证读写权限。
关键区别：
-
fopen()会触发系统打开操作，有副作用（如增加文件引用计数、触发挂载、唤醒休眠设备），且在 NFS 等远程文件系统上可能阻塞 -
access()是轻量元数据查询，但 Windows 的_access()对 Unicode 路径支持差，且不识别重解析点（如 NTFS 符号链接） - 两者均不区分“路径存在但不可读”和“路径根本不存在”，错误码都是
ENOENT或EINVAL
避免用 stat() 手动解析结构体判断
虽然 stat() 能拿到完整元数据（大小、修改时间、类型），但用它来“判断存在”属于过度设计，且引入平台差异风险。
问题集中在：
- Linux/macOS 用
struct stat，Windows 需用_stat64或GetFileAttributes()，代码分支多 - 调用后必须检查
st_mode是否为 0（表示失败），而非只看返回值——某些文件系统（如某些 FUSE 实现）可能填充部分字段但返回 -1 - 若路径含中文或特殊字符，
stat()在窄字符接口下易因编码不匹配返回ENOENT（实际存在）
除非你本就需要文件大小或时间戳，否则别为“存在性检查”额外引入 stat()。
路径字符串本身有效性 ≠ 文件存在性
很多开发者混淆“路径语法合法”和“文件真实存在”。例如："../data//config.json" 在语法上完全合法（经 std::filesystem::path 规范化后为 "../data/config.json"），但父目录可能根本不存在。
真正要检查的不是字符串，而是路径所指的最终实体。因此：
- 不要用正则匹配路径格式（如
^[a-zA-Z]:[/\\]）代替存在性检查 - 不要依赖
std::filesystem::path::has_filename()或is_absolute()做存在判断 - 若路径来自用户输入，先做
fs::weakly_canonical()或手动规范化，再传给exists()——否则相对路径在不同工作目录下结果不同
最隐蔽的坑：某些容器环境或沙箱中，/proc/self/fd/ 下的路径看似存在，但 exists() 可能返回 false，因为内核不将其视为常规文件系统对象。
