std::filesystem::exists 返回 false 但文件存在，主因是路径语义不匹配：默认不追踪符号链接、相对路径依赖启动时工作目录、权限不足或 windows 路径格式/长度限制；应检查 error_code、用 absolute/canonical、避免热循环调用。
std::filesystem::exists 为什么返回 false 却文件明明存在
常见现象是 std::filesystem::exists(path) 返回 false，但用 shell 或资源管理器确认文件确实存在。根本原因通常是路径语义不匹配：该函数对符号链接默认不追踪（即 exists 检查的是链接本身是否存在，而非它指向的目标），且不自动处理相对路径的当前工作目录上下文。
- 若
path是符号链接，且链接文件存在但目标被删，exists仍返回true；想检查目标存在性，得用std::filesystem::is_regular_file(path) && std::filesystem::exists(path)或先std::filesystem::canonical(path) - 相对路径依赖程序启动时的 cwd，不是源码所在目录——调试时 IDE 启动路径和终端运行路径常不同，建议用
std::filesystem::absolute(path)预处理 - 权限不足时（如只读挂载、无执行权的目录），
exists可能静默失败并返回false，此时应配合std::filesystem::status(path).type()判断是否为file_type::none
std::filesystem::exists 在 Windows 上要注意路径分隔符和长路径
Windows 对路径长度和格式更敏感，std::filesystem 虽会自动转换 / 为 ，但若原始字符串含裸反斜杠（如 "C: emp est.txt"），会被编译器解析为转义序列，导致路径损坏。
- 永远用正斜杠或双反斜杠写字符串：
"C:/temp/test.txt"或"C:\temp\test.txt" - 超过 260 字符的路径需启用长路径支持（Windows 10 1607+），并在 manifest 中声明，否则
exists直接失败；也可用\?前缀绕过限制，但需确保路径已绝对化：std::filesystem::exists(L"\\?\C:\very\long\path") - 注意驱动器号大小写：Windows 文件系统不区分大小写，但
std::filesystem::exists的实现可能因底层 API 行为产生意外结果，统一用小写驱动器（如"c:/..."）更稳妥
std::filesystem::exists 性能开销比想象中大，别在热循环里调用
每次调用都会触发一次系统调用（Linux/macOS 的 stat，Windows 的 GetFileAttributesEx），即使只是判断存在性。在高频场景（如网络服务每请求检查配置文件）会造成明显延迟。
- 避免在 tight loop 中反复调用：
while (exists(p)) { ... }应改用单次检查 + 缓存结果或监听文件系统事件（如 inotify / ReadDirectoryChangesW） - 若只需区分“存在/不存在/不可访问”，用
std::filesystem::status(path)一次获取完整状态，比多次调用exists、is_directory更高效 - 调试时可临时加
std::chrono测量耗时——本地 SSD 上单次调用通常 10–50μs，但 NFS 或杀毒软件 hook 后可能飙升到毫秒级
替代方案：什么时候不该用 std::filesystem::exists
当目标只是打开文件或读取内容时，直接尝试操作 + 捕获异常，比先 exists 再操作更可靠、更原子。
立即学习“C++免费学习笔记（深入）”；
-
exists和后续open之间存在竞态窗口：文件可能在检查后被删除或重命名，导致逻辑错误；而std::ifstream f(path)失败时自然捕获问题 - 某些平台（如嵌入式或沙盒环境）可能禁用
stat类系统调用，但允许 open；此时exists必然失败，而实际 I/O 可能成功 - 若业务逻辑真正需要“存在性”语义（如初始化前校验资源目录结构），才用
exists；否则优先走“面向失败编程”：操作 → 处理 error_code
最易被忽略的一点：std::filesystem::exists 不抛异常，但会设置 std::error_code& 参数。很多人只看返回值，却没检查 error_code 是否非零——这会导致把“权限拒绝”误判为“文件不存在”。
