std::filesystem::is_directory() 返回 false 的主因是路径不存在、无权限或悬空软链接，正确用法是先调用 std::filesystem::exists(path) 确认存在，再调用 is_directory()；避免相对路径、编码错误和尾部斜杠干扰，禁用非标准的 _is_directory()。
std::filesystem::is_directory() 怎么用才不会返回 false
直接说结论：std::filesystem::is_directory() 不会“误判”，但绝大多数情况下它返回 false 是因为路径不存在、没权限，或者你传了个 dangling symlink（悬空软链接）且没处理。它本身不抛异常，但依赖底层文件系统状态。
使用前必须确保：std::filesystem::exists(path) 为 true，否则结果无意义——C++ 标准明确要求：对不存在路径调用 is_directory() 返回 false，哪怕路径语法上像目录（比如带尾部 /）。
- Windows 下注意路径分隔符兼容性：用
/或\都行，std::filesystem自动 normalize - Linux/macOS 下软链接需显式判断：默认不解析 symlink，
is_directory(path)检查的是 link 本身是否为目录类型；若想检查目标，用is_directory(std::filesystem::read_symlink(path)) - 权限不足时（如只读挂载点、/proc 下某些条目），
exists()可能返回false，此时is_directory()必然false—— 不是函数错了，是系统拒绝告诉你元数据
为什么 _is_directory() 这种下划线开头的函数不能用
你看到的 _is_directory() 很可能来自旧版 MinGW、某些 Windows SDK 头文件，或非标准扩展。它不是 C++ 标准库的一部分，也不在 <filesystem></filesystem> 中定义。强行使用会导致：
- 跨平台编译失败（GCC/Clang 默认不提供，MSVC 也不保证）
- 链接错误：找不到符号，尤其开启
-std=c++17或更高时 - 行为不一致：某些实现把它当作内部函数，参数签名和语义可能随时变更
正确做法只有：包含 <filesystem></filesystem>，用 std::filesystem::is_directory()。别试图“绕过 namespace”或找宏替代。
判断前必须处理的三个典型错误路径
即使写了 is_directory(path)，实际运行仍常出错，根源几乎都出在路径值本身。以下三类最易踩坑：
-
path是相对路径且当前工作目录已变：比如程序从 IDE 启动时 cwd 是项目根，但命令行切换到子目录后执行，"data/"就可能找不到 → 建议统一转成绝对路径：std::filesystem::absolute(path) - 路径含中文或 Unicode 字符但编译器/终端编码不匹配：Windows 控制台默认 GBK，而
std::filesystem要求 UTF-8 字节序列 → 在 MSVC 下启用/utf-8编译选项，或用std::filesystem::u8path(u8"中文目录") - 路径末尾有冗余分隔符导致
exists()失败：例如"./config//"在部分系统上被 normalize 成"./config"，但若"config"是文件，"config/"就不存在 → 用std::filesystem::canonical(path)或先remove_trailing_separator()
性能敏感场景下要不要缓存 is_directory 结果
频繁判断同一路径（比如循环遍历目录内容时反复检查子项）确实有开销，但缓存需谨慎：
- 单次调用
is_directory()底层通常触发一次stat()系统调用，开销不大；比自己手写opendir()+readdir()判断更轻量 - 缓存的前提是路径内容不变：若其他进程可能修改该路径（创建/删除/重命名），缓存结果几秒后就失效，反而引入 bug
- 真正值得优化的是批量判断：用
std::filesystem::directory_iterator遍历时，每个directory_entry对象自带is_directory()方法，它复用已获取的status，比单独调用快得多
所以与其手动缓存，不如直接用迭代器接口——这是标准库设计者已经为你优化好的路径。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
