C++remove_all递归删除目录树

2026-04-11 03:15:28 1839阅读 0评论

`std::filesystem::remove_all`：递归删目录，别被“成功”骗了

上周帮同事修一个构建脚本，他抱怨：“remove_all("build") 明明返回 true，可 build/obj/ 里还有几个 .o 文件没删干净。”
我第一反应是权限问题——果然，build/obj/ 是由另一个用户临时创建的只读子目录，C++ 标准库没抛异常，只是默默跳过。

这事儿挺典型：remove_all 不是“保证删光”，而是“尽最大努力删，失败就绕过”。它不 throw，也不 warn，更不告诉你哪一层卡住了。你得自己补上兜底逻辑。

它到底做了什么？

C++17 引入 std::filesystem::remove_all(path)，语义很直白：递归删除 path 下所有内容（包括 path 自身），并返回成功删除的文件/目录数量（类型为 uintmax_t）。

但注意两个关键细节：

它按深度优先遍历，先删子项，再删父目录；
遇到任何不可访问项（权限不足、正被占用、路径不存在等），直接跳过，不中断流程，也不报错。

也就是说：返回值 0 ≠ “啥都没删”，而可能是“删了一半，中途全挂了”；返回值 127 也 ≠ “全部删净”，而只是“它数到的、能删的那些”。

为什么你会误判“删除成功”？

常见误区有三个：

只看返回值是否非零
```
if (fs::remove_all("temp")) { /* 以为稳了 */ }  
```
错。只要删掉任意一个东西（哪怕只是空子目录），就返回 >0。temp/lockfile.lock 被进程占用？删不掉，但它照样删了 temp/logs/ 下的 3 个空目录，返回 3 —— 你却信了。
忽略 std::filesystem::status_error 异常
remove_all 本身不抛异常，但内部调用 status() 检查路径时，若传入非法路径（如含 \0 或超长名），可能抛 filesystem_error。很多人没包 try/catch，程序直接崩。
没区分“路径不存在”和“删失败”
remove_all("nonexistent") 返回 0，这是合规行为（标准明确说“若 path 不存在，返回 0”）。但你如果靠 == 0 判断“删完了”，就会把“本来就没东西”和“想删却删不动”混为一谈。

真实可用的健壮写法

要真正掌控删除过程，得自己走一遍树，逐层控制：

bool safe_remove_all(const fs::path& p) {
    if (!fs::exists(p)) return true; // 不存在 = 已满足目标

    bool all_ok = true;
    // 先递归处理子项
    for (auto& entry : fs::recursive_directory_iterator(p)) {
        try {
            if (fs::is_regular_file(entry)) {
                if (!fs::remove(entry.path())) all_ok = false;
            } else if (fs::is_directory(entry)) {
                if (!fs::remove(entry.path())) all_ok = false;
            }
        } catch (const fs::filesystem_error&) {
            all_ok = false; // 记录失败，但继续尝试其他项
        }
    }
    // 最后删自己
    if (fs::is_directory(p)) {
        if (!fs::remove(p)) all_ok = false;
    }
    return all_ok;
}

这段代码的关键改进在于：

显式捕获每一步异常，不依赖 remove_all 的静默策略；
失败不中断循环，确保尽可能多清理；
最终返回布尔值，语义清晰：true = 所有可操作项均已清理。

还得防哪些“软性失败”？

Windows 下的只读文件：remove 会失败，需先 fs::permissions(p, fs::perms::owner_write, fs::perm_options::add)；
Linux 下的 sticky 目录（如 /tmp 子目录）：即使有写权限，删别人创建的文件仍会拒；
符号链接本身：remove_all 默认只删 link 文件，不进目标路径——这点常被忽略，尤其当 build/ 指向 SSD 分区时，你以为删了，其实只是断了链接。

所以，删前加一句 fs::permissions(p, fs::perms::owner_all, fs::perm_options::replace) 往往比硬刚权限错误更省事。