一致，但需启用C++17且链接正确运行时库；它基于stat或GetFileAttributesW封装，自动处理路径分隔符与符号链接策略，不跟随软链接、需用absolute()归一化路径，返回false不报错是设计使然。
std::filesystem::is_directory 在 Windows 和 Linux 上行为一致吗
一致，但前提是你的编译器启用了 C++17 标准且链接了正确的运行时库。它不是宏或平台条件编译的别名，而是基于 stat（Linux/macOS）或 GetFileAttributesW（Windows）封装的跨平台接口，底层自动处理路径分隔符、符号链接解析策略等差异。
常见错误现象：std::filesystem::is_directory 对软链接返回 false（默认不跟随），而你期望它判断目标是否为目录；或者传入相对路径时当前工作目录意外改变，导致判断结果漂移。
- 始终用
std::filesystem::status()或std::filesystem::symlink_status()显式选择是否跟随链接 - 传入路径前先用
std::filesystem::absolute()归一化，避免相对路径受 cwd 影响 - Windows 下注意路径字符串是否含非法字符（如
:在非驱动器位置）、是否以\结尾（不影响判断，但易引发后续操作歧义）
为什么 std::filesystem::is_directory(path) 返回 false 却没报错
因为 std::filesystem::is_directory 是“状态查询函数”，它只检查路径是否存在且类型匹配，不抛异常——即使路径根本不存在，它也安静地返回 false。这是设计使然：多数场景下，你只需要“是/否”答案，而不是“为何不是”。
使用场景：配置加载、资源扫描、缓存目录预检。如果你需要区分“路径不存在”和“存在但不是目录”，必须配合 std::filesystem::exists() 或捕获 std::filesystem::status_error 异常。
立即学习“C++免费学习笔记（深入）”；
- 安全写法：
if (std::filesystem::exists(p) && std::filesystem::is_directory(p)) { ... } - 想明确失败原因？改用
std::error_code ec重载版本：std::filesystem::is_directory(p, ec)，之后检查ec.value()是否为 0 - 别依赖
try/catch捕获std::filesystem::filesystem_error来判断类型——它只在底层系统调用出错时抛出（如权限拒绝、路径过长），不是类型不匹配的信号
替代方案：_is_directory 这种 C 风格函数还能用吗
不能，_is_directory 不是标准 C++ 函数，也不是 POSIX 或 Win32 API 的公开接口。它可能是某些旧版 MSVC 头文件里的内部符号，或第三方库的私有实现，跨平台构建必然失败。硬用会导致链接错误（Linux 下找不到符号）或隐式截断（Windows 下参数类型不匹配）。
性能与兼容性影响：手写 stat + 类型位判断（S_ISDIR）或调用 GetFileAttributes 虽然可行，但你要自己处理路径编码（UTF-8 vs UTF-16）、符号链接循环、权限掩码差异、以及 macOS 上对某些挂载点的特殊行为——这些正是 std::filesystem 替你屏蔽的复杂性。
- 坚持用
std::filesystem::is_directory，C++17 起所有主流编译器（GCC 8+, Clang 7+, MSVC 2017+）都已完整支持 - 若必须用 C 风格，选标准 POSIX
stat()（Linux/macOS）或 Win32GetFileAttributesExW()，但得写 #ifdef 分支，且无法统一处理 Unicode 路径 - 别试图用
opendir()+closedir()判断——它在无读权限但路径是目录时会失败，语义不等价
真正容易被忽略的是：std::filesystem::is_directory 对路径末尾斜杠不敏感，但某些 shell 或构建工具会因斜杠存在而改变行为；另外，容器环境或网络文件系统（如 NFS、SMB）可能让 status() 调用变慢甚至超时，这时候加 std::filesystem::file_time_type 缓存或异步预检更实际。
