std::filesystem::exists() 是 c++17 起判断路径是否存在且可访问的最可靠方法，不区分类型，比 fopen() 或 access() 更安全，需包含头文件并链接 -lstdc++fs 或启用 -std=c++17。
用 std::filesystem::exists() 最可靠
C++17 起，std::filesystem::exists() 是判断路径是否存在且可访问的首选。它不区分文件、目录或符号链接，只回答“这个路径在文件系统里有没有对应实体”。比手动 fopen() 或 access() 更安全，因为后者可能受权限干扰（比如路径存在但无读权限，access() 返回 -1，容易误判为“不存在”）。
实操建议：
- 必须包含
#include <filesystem></filesystem>，并链接-lstdc++fs（GCC 早期版本）或启用 C++17 标准（-std=c++17） - 传入的
std::filesystem::path对象会自动处理路径分隔符（/和都行），不用自己转义 - 如果路径是相对路径，判断基于当前工作目录 —— 这点常被忽略，导致测试时正常、部署后失效
- 示例：
std::filesystem::path p = "config.json";<br>if (std::filesystem::exists(p)) {<br> // 存在<br>}
std::filesystem::status() 能进一步区分类型
仅知道“存在”还不够？比如你要确认是个普通文件而非目录，就得用 std::filesystem::status()。它返回 std::filesystem::file_status，可配合 is_regular_file()、is_directory() 等判断具体类型。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 直接对不存在的路径调用
status()会抛出std::filesystem::filesystem_error异常 —— 必须捕获或先用exists()预检 - 符号链接默认被解引用（即查目标文件状态），如需检查链接本身，得用
symlink_status() - 某些嵌入式或旧系统（如部分 Android NDK 版本）不完全支持
std::filesystem，此时需降级方案
Windows 下用 GetFileAttributesW() 更轻量
如果项目不能用 C++17，或需要极致控制（比如避免异常、绕过 STL 的路径解析开销），Windows 原生 API 是更直接的选择。用 GetFileAttributesW() 判断存在性快且稳定，返回值为 INVALID_FILE_ATTRIBUTES 即表示不存在或无权限。
使用场景和坑点：
- 必须传宽字符路径（
L"xxx"），UTF-8 字符串要先转换，否则中文路径大概率失败 - 返回值为
FILE_ATTRIBUTE_DIRECTORY表示是目录，FILE_ATTRIBUTE_DEVICE等特殊属性需排除，否则可能把设备文件误认为普通文件 - 不支持跨平台，Linux/macOS 得换
stat()，代码分支变多 —— 如果只是简单存在性检查，别为这点性能牺牲可维护性
不要用 fopen() 或 ifstream::is_open() 做存在性判断
这是最常见也最危险的误区。这两个接口本质是“尝试打开”，而打开失败原因极多：权限不足、磁盘满、NFS 挂载中断、甚至防病毒软件拦截……它们返回 false 并不等于“文件不存在”。
典型错误写法：
FILE* f = fopen("data.bin", "r");<br>if (!f) {<br> // 这里就认定文件不存在？错。<br> // 可能只是你没读权限，或者文件被其他进程独占锁住。<br>}
更糟的是，有些代码还会接着用 fclose(f)（未判空）导致崩溃。记住：IO 函数 ≠ 文件系统查询函数。
如果你已用到 std::filesystem，就别倒退；如果真受限于老标准，宁可用 stat()（POSIX）或 GetFileAttributesW()（Windows）这类专用于元信息查询的系统调用。
路径有效性远不止“存不存在” —— 权限、挂载状态、符号链接循环、长路径截断（尤其 Windows MAX_PATH）、编码一致性……这些全在 exists() 底层默默处理了。别自己造轮子去碰。