std::Filesystem::exists 默认抛出 filesystem_error 异常而非返回 false，应优先使用带 std::error_code& 参数的重载；对符号链接自动解引用，需确认软链本身存在时改用 symlink_status；windows 下注意路径标准化与 UNC 可达性；性能低于裸 stat，高频场景需缓存 status。
std::filesystem::exists 会抛异常，不是所有路径都能直接查
std::filesystem::exists 在遇到权限不足、符号链接断裂、路径过长或跨文件系统挂载点不可达等情况时，**默认抛出 std::filesystem::filesystem_error 异常**，而不是返回 false。很多新手误以为它像 C 风格的 access() 那样静默失败。
实际使用必须处理异常，或者改用带 std::error_code& 参数的重载版本：
std::error_code ec; bool exists = std::filesystem::exists(path, ec); // ec 为非零值表示出错（如 permission_denied、no_such_file_or_directory） // 此时 exists 的返回值不可靠，应以 ec 是否为 0 为准- 推荐始终使用带
ec的重载，尤其在服务端或嵌入式等异常处理成本高的场景 - 若忽略
ec且路径非法（比如/proc/self/fd/999），程序直接崩溃 - 注意：即使
ec为 0，exists返回false也不代表“一定不存在”——某些只读挂载或 NFS 延迟可能让内核返回ENOENT误判
exists 对目录和文件一视同仁，但 symlink_status 更准
std::filesystem::exists 检查的是“路径所指对象是否存在”，对符号链接会自动解引用。这意味着：
- 若
path是指向无效目标的软链，exists(path)返回false - 若只想确认软链本身存在（不管目标是否有效），该函数不适用
此时应改用 std::filesystem::symlink_status：
立即学习“C++免费学习笔记（深入）”；
std::error_code ec; auto s = std::filesystem::symlink_status(path, ec); if (!ec && s.type() != std::filesystem::file_type::not_found) { // 路径本身存在（含 broken symlink） }-
status()和symlink_status()的区别关键在是否解引用：前者进到目标里看，后者只看路径这一层 - 判断“文件是否存在且是普通文件”应组合使用：
exists(p, ec) && is_regular_file(p, ec)，不能只靠exists
windows 下路径分隔符和大小写敏感性要特别注意
Windows 默认不区分大小写，但 std::filesystem 的行为受底层 API 和卷格式影响：
- NTFS 卷上，
exists("C:\Temp\File.TXT")可能返回true即使实际文件名是file.txt - 但若路径含非法字符（如
、|）或使用正斜杠/作为分隔符，部分旧版 MSVC STL 会提前报错，而非交由系统判断 - 建议统一用
std::filesystem::path构造路径，它会自动标准化分隔符：std::filesystem::path("a/b/c")在 Windows 上转为abc
另外，UNC 路径（如 \\server\share\file）需确保网络可达，否则 exists 会卡住或超时（取决于系统配置），不是立刻返回 false。
性能开销比 stat 略大，高频调用需缓存
std::filesystem::exists 底层通常调用 stat() 或 GetFileAttributesEx()，但额外封装了路径解析、编码转换（如 UTF-8 ↔ UTF-16）、异常对象构造等逻辑。实测比裸 stat 慢 10%–30%。
- 不要在 tight loop 中反复调用，比如轮询文件生成 —— 改用
inotify（linux）或ReadDirectoryChangesW（Windows） - 若需多次检查同一路径，可缓存
std::filesystem::status结果（含mtime和file_size），避免重复系统调用 - 注意：缓存状态不解决并发修改问题；若其他进程可能删/改文件，仍需每次重新 check
真正容易被忽略的是：exists 不保证后续操作一定成功 —— 检查完瞬间被删除，open() 仍可能失败。它只是快照，不是锁。