directory_entry：C++17 文件系统里那个“不说话但啥都知道”的目录小管家

你有没有试过写个 C++ 程序，想遍历一个文件夹，顺便知道每个条目是文件、子目录、符号链接，还是根本打不开的权限黑洞？以前得靠 stat() + 字符串拼接 + 一堆 #ifdef _WIN32 宏，稍不留神就踩进路径分隔符或时区解析的坑里。C++17 引入 <filesystem> 后，directory_entry 就像被悄悄塞进标准库的瑞士军刀——它不主动输出，但你一问，它立刻报出完整身份信息。

它不是迭代器，也不是路径对象，而是一个轻量级封装体：内部持有一个 path 和一组预缓存的属性（取决于构造方式）。关键在于——它把“查一次系统调用，拿到所有基础元数据”这件事，打包成一次可控操作，避免你在循环里反复 stat() 导致性能雪崩。

最常被忽略的一点：directory_entry 的构造本身不一定触发系统调用。比如 for (const auto& entry : fs::directory_iterator(dir)) 中的 entry，底层通常在首次访问 .status() 或 .is_regular_file() 时才真正读取 inode 信息。但如果你显式调用 fs::directory_entry{p, fs::symlink_option::follow}，构造时就会 resolve 符号链接并获取目标状态。这个时机差，直接影响程序在海量小文件下的响应速度。

怎么判断一个条目是不是目录？别急着写 entry.path().extension() == ".d"——那是 Unix 老派思维。正确姿势是：

if (entry.is_directory()) { /* 真·目录 */ }

注意：is_directory() 返回 true 仅当该路径当前指向一个目录实体（无论是否可进入）。如果路径是坏链接，它会返回 false，而不是抛异常——异常只发生在你明确调用 .status() 且系统调用失败时（比如权限不足）。

更实用的场景：你想跳过所有隐藏文件（以.开头），但又不想漏掉 macOS 的 .DS_Store 或 Linux 的 .git。这时候 entry.path().filename().string()[0] == '.' 是直观解法，但要注意：Windows 下没有“隐藏文件”语义，.gitignore 在 NTFS 上就是普通文件。真正的跨平台隐藏逻辑，得结合 entry.status().permissions() & fs::perms::owner_exec？不，那是执行权限。标准库没定义“隐藏”，所以你的业务逻辑必须自己定义边界——这点很多教程避而不谈。

说到权限，entry.permissions() 返回的是 fs::perms 枚举组合值。但请注意：它反映的是文件系统原生权限位，不是当前进程能否读写。比如一个 rw-r--r-- 的文件，在只读挂载卷上，permissions() 依然返回可写，但 std::ofstream 会失败。权限字段是“静态快照”，不是运行时能力探针。

时间戳呢？entry.last_write_time() 返回 fs::file_time_type，这是 C++20 前唯一能精确到纳秒（取决于平台）的时间类型。但别直接拿它和 std::chrono::system_clock::now() 比——它们时钟域不同。要转换，得用 fs::file_time_type::clock::to_time_t() 或 C++20 的 std::chrono::clock_cast。日常开发中，若只需判断“是否比某时间新”，用 entry.last_write_time() > ref_time 完全可行，因为比较操作符已重载。

一个容易踩的坑：directory_entry 的 path() 返回的是相对路径片段（相对于迭代起点），不是绝对路径。如果你在递归遍历时拼错路径，比如 fs::path("log") / entry.path()，而 entry.path() 已经是 "/var/log/app.log"，结果就是 /var/log/app.log ——等等，这不对？不，fs::path 的 / 运算符会自动 normalize，遇到绝对路径会丢弃左侧。所以安全做法是统一转绝对路径再拼：fs::absolute(base) / entry.path().lexically_normal()。

最后说个冷知识：directory_entry 支持移动语义，但不支持拷贝。这意味着你可以把它存在 std::vector 里（移动构造），但不能 auto x = y;。为什么？因为它的内部状态（如预缓存的 file_status）一旦复制，就可能和原始对象产生状态歧义。标准委员会宁可让你显式调用 .status() 重新获取，也不愿承担隐式共享的风险。

总结下来，directory_entry 的价值不在炫技，而在克制——它把系统调用的不确定性收束到明确的方法调用里，把路径与元数据的耦合降到最低。你不需要记住二十个 API，只要盯住三个核心动作：构造时决定要不要立即 resolve 链接、访问时按需触发状态查询、处理时始终基于 path 对象做路径运算。剩下的，交给它安静地站在那里，等你发问。