C++里用is_directory判断目录？别急，先搞清它到底在“看”什么

写C++文件操作代码时，你可能随手就写了这么一行：

if (fs::is_directory(p)) { /* 处理目录 */ }

看起来干净利落。但上周帮同事排查一个bug时，发现程序在Windows上明明点开是空文件夹，is_directory却返回false；换到Linux又正常了。后来追下去才发现——is_directory不是在“看路径长得像不像目录”，而是在“查系统返回的文件属性”。这个细节，恰恰是多数教程没讲透、新手踩坑最勤的地方。

is_directory属于C++17引入的<filesystem>标准库，但它不是魔法，背后调用的是操作系统API（比如Windows的GetFileAttributesW，Linux的stat()）。这意味着：它只对已存在的路径有效，且结果完全取决于系统是否成功返回了“这是一个目录”的元信息。

所以第一个实用提醒来了：
is_directory对不存在的路径永远返回false，哪怕路径语法完全合法（比如"data/logs"）。
这不是bug，是设计使然——它不负责“预测”，只负责“确认”。如果你需要区分“路径不存在”和“存在但不是目录”，得配合exists()一起用：

fs::path p = "config";
if (!fs::exists(p)) {
    std::cout << "路径根本不存在\n";
} else if (fs::is_directory(p)) {
    std::cout << "确认是目录\n";
} else {
    std::cout << "存在，但它是文件或符号链接\n";
}

这里有个容易被忽略的陷阱：符号链接（symlink）。
在Linux/macOS下，如果p是个指向目录的软链接，is_directory(p)默认返回false——因为它检查的是链接本身（类型是symlink），而不是链接目标。要穿透链接检查目标，得加fs::status(p)或直接用fs::is_directory(fs::read_symlink(p))。而Windows的junction点行为又略有不同……所以跨平台时，别假设is_directory会自动解引用，明确你的意图：是要检查“这个路径实体是不是目录”，还是“这个路径最终指向的是不是目录”。

另一个真实场景：用户输入了一个路径字符串，你想快速过滤出其中的目录。这时候直接对每个字符串调用is_directory？小心权限问题。
比如在Linux上，你有读取/proc的权限，但/proc/12345/fd这种路径，即使存在，普通用户也常因权限不足导致stat()失败——此时is_directory会抛std::filesystem::filesystem_error异常。它不会静默失败，而是明确告诉你“我查不了”。所以生产环境务必包住异常：

try {
    if (fs::is_directory(p)) {
        // 安全处理
    }
} catch (const fs::filesystem_error& e) {
    // 常见原因：权限不足、路径过长、挂载点不可达
    std::cerr << "检查目录失败：" << e.what() << "\n";
}

还有个反直觉点：. 和 .. 这类特殊目录项，is_directory一定返回true吗？
答案是：不一定。在某些受限环境（如容器内chroot、FUSE挂载的只读文件系统），. 可能无法获取属性。更稳妥的做法是——对这类已知语义的路径，直接逻辑判断，别依赖系统调用。毕竟，p == "." || p == ".."比一次系统调用更轻量、更确定。

最后说个调试技巧。当is_directory行为诡异时，别只盯着代码，用命令行验证底层事实：

• Linux/macOS：ls -ld path 看输出开头是不是d（目录）或l（链接）
• Windows：dir path 看是否标为<DIR> 如果命令行都报“找不到”，那C++里当然也查不到——问题不在代码，而在路径来源或运行时环境。

总结一下关键动作点：
✅ 用exists()前置判断路径是否存在；
✅ 对符号链接，明确是否需要read_symlink()后检查；
✅ 永远捕获filesystem_error，尤其在遍历未知目录时；
✅ 避免对./..等特殊路径过度依赖系统调用；
✅ 调试时优先用系统命令验证路径状态，再回看C++逻辑。

is_directory不是开关，而是一面镜子——它忠实地反射系统此刻能告诉你的信息。理解它的边界，比记住函数签名更重要。下次看到它返回false，先问一句：是它真不是目录，还是它根本没机会看清？