c++如何获取文件夹占用的空间大小_递归计算目录容量【详解】

先说几个核心判断。计算文件夹大小，如果用C++17，那 std::filesystem 就是最趁手的工具；如果项目古老，在Windows上得用 FindFirstFileEx 自己折腾，Linux/macOS则离不开 stat() 和 opendir() 的组合拳。但无论哪种方式，真正的难点从来不是遍历本身，而是对边界情况的处理和对“大小”这个概念的界定。

用 std::filesystem::recursive_directory_iterator 遍历目录并累加文件大小

自C++17起，标准库自带的 std::filesystem 是跨平台获取目录容量的不二之选。关键不在于“如何统计子目录个数”，而在于对每个 std::filesystem::directory_entry 判断是否为常规文件，并调用 file_size() 获取字节数。

但这里有个常见的坑：忽略异常。某些文件可能因为权限不足或路径被占用而抛出 std::filesystem::filesystem_error，不捕获的话，程序直接崩溃给你看。

• 必须用 try/catch 包裹 file_size() 调用，跳过那些不可读的项。
• 避免重复计算符号链接指向的目标。好在默认情况下，recursive_directory_iterator 不会解引用符号链接。
• 记住，is_regular_file() 对于符号链接、目录、socket 等都会返回 false，只累加它返回 true 的条目。

uint64_t get_directory_size(const std::filesystem::path& p) {
    uint64_t total = 0;
    for (const auto& entry : std::filesystem::recursive_directory_iterator(p)) {
        try {
            if (entry.is_regular_file()) {
                total += entry.file_size();
            }
        } catch (const std::filesystem::filesystem_error&) {
            // 忽略权限不足、路径失效等错误
            continue;
        }
    }
    return total;
}

Windows 下用 FindFirstFileExW + 手动递归的兼容性陷阱

如果项目必须支持C++14，或者因为某些嵌入式STL实现而禁用了 std::filesystem，那么Windows原生API是可行的替代方案。但要注意，FindFirstFileExW 默认不进入子目录，你必须手动递归调用，这很容易导致栈溢出或路径拼接出错。

典型问题包括：MAX_PATH 限制（260字符）、长路径未启用Unicode支持、WIN32_FIND_DATAW 中 nFileSizeHigh 和 nFileSizeLow 需要组合成64位整数。

• 必须在工程中定义 UNICODE 和 _UNICODE，否则宽字符API不可用。
• 路径拼接建议用 std::wstring 配合 std::filesystem::path::generic_wstring()。即使不使用整个filesystem模块，也可以借用其强大的路径处理能力。
• 如果递归深度较大，建议改用栈模拟（std::stack），避免函数调用栈爆炸。

Linux/macOS 下 stat() 和 opendir() 组合的注意事项

在POSIX环境下，无法用一个系统调用就拿到整个目录的大小。标准流程是：opendir() → 遍历 readdir() → 对每个条目调用 stat() 判断类型和大小。这里最容易踩的坑是符号链接和硬链接的处理。

stat() 默认会跟随符号链接。如果你想跳过链接本身（不计入目标文件），应该改用 lstat()。而硬链接会被多次统计（不同路径指向同一个inode），如果需要去重，得用 st_dev 和 st_ino 缓存已经见过的inode。但通常来说，我们计算“磁盘占用”指的是实际写入的块数，硬链接不应该去重。

• 务必检查 dirent::d_type（如果可用），用它来代替反复调用 lstat()，能显著提升性能。
• st_size 对目录来说恒为0，必须依赖 S_ISREG() 宏来判断是否为常规文件。
• 某些文件系统（如ext4加密目录）可能对非属主返回 -1 的 st_size，所以需要检查 stat() 的返回值是否为0。

为什么不能只靠 du -sh 的输出做精度对比？

终端命令 du 默认按文件系统块大小（如4KiB）向上取整统计，而 std::filesystem::file_size() 返回的是逻辑字节数。两者数值天然不一致，尤其是对于小文件多的目录，差异可能达到数倍。

举个例子：一个1字节的文件，在4KiB块大小的文件系统上，物理上占用4096字节空间。du 会报4K，而 file_size() 返回1。如果你的需求是“用户感知的文件体积总和”，用 file_size()；如果是“真实磁盘占用”，则需要结合 statfs()（Linux）或 GetDiskFreeSpaceEx()（Windows）换算块用量。但后者无法精确到单个目录，只能估算。

所以说，真正难的不是遍历，而是明确你到底要的是“逻辑大小”还是“物理占用”。在绝大多数场景下，用户问“这个文件夹多大”，指的就是前者。直接累加 file_size() 就足够了，别被 du 的结果带偏了方向。