处理非空文件夹的递归删除，在很多实际项目中都是一个绕不开的需求。虽然手写递归逻辑并不复杂，但标准库在 C++17 中已经提供了现成的方案——std::filesystem::remove_all，而且它才是真正经过工程考验的推荐做法。不过，这条“捷径”上埋着几个坑，如果没留意，轻则删不干净，重则程序崩溃。下面把几个关键点拆开来说。
Windows下用 std::filesystem::remove_all 最简方案
只要编译器支持 C++17（MSVC 2017+、GCC 8+、Clang 7+ 都行），并且项目启用了 std::filesystem，那么 std::filesystem::remove_all 就是递归删除非空目录的首选。它原生处理了目录遍历、权限检查、子项顺序删除，完全不需要自己手写递归逻辑。
但有一个常见的忽略点：异常处理。这个函数在遇到只读文件、被占用文件或权限不足时会抛出 std::filesystem::filesystem_error，如果不捕获，程序直接崩溃。所以实际使用时，必须用 try/catch 包裹起来，至少把错误信息打印出来，方便定位问题。
另外还有几个实操建议：
- 确保链接了
std::filesystem库（MSVC 默认启用；GCC/Clang 需要加-lstdc++fs） - 调用前最好用
std::filesystem::is_directory检查一下路径是不是目录，避免对文件调用导致未定义行为 - 路径必须是目录，否则行为未定义
try {
std::filesystem::remove_all("path/to/dir");
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << "删除失败: " << e.what() << "n";
}
Linux/macOS 下 remove_all 的兼容性注意点
标准库接口虽然一致，但不同平台底层的差异还是值得留意的。比如 Linux 下如果目录里包含符号链接，remove_all 默认只删除链接本身，不会递归进入链接指向的目标目录。而 Windows 不支持符号链接目录，所以不会有这个问题。
更关键的是权限模型：Linux/macOS 上删除目录内文件，依赖的是父目录的写权限（w），而不是文件自身的权限。很多人容易踩的坑是：以为把文件 chmod 成 644 就能删，结果发现根本不行——得先保证父目录可写。
实操建议：
- 确认目标目录的父级路径是否可写，可以用
std::filesystem::status(path).permissions() & std::filesystem::perms::owner_write来检查 - 尽量避免用 root 权限硬删，正确的做法是提前修正权限，或者用
std::filesystem::permissions临时提升 - 如果需要穿透符号链接（即删除软链指向的内容），必须先 resolve 再删，
remove_all不会自动做这一步
手写递归删除时为什么不能直接用 std::filesystem::remove
std::filesystem::remove 只能删除单个文件或空目录。如果对非空目录调用，它直接返回 false（不抛异常），导致循环里跳过它，最终目录残留——这是最容易被忽略的语义陷阱。
正确的做法是先遍历子项，逐个递归删除，最后再删自身。但要注意顺序和异常安全：
- 必须后序遍历：先删子项，再删父目录。否则目录非空会导致删除父目录失败
- 遍历时不能边迭代边删（
directory_iterator在目录被删后失效），应该先收集所有路径，再批量处理 - 每个子项删除都应该独立使用
try/catch，避免一个失败中断整个流程
void remove_recursive(const std::filesystem::path& p) {
if (!std::filesystem::exists(p)) return;
if (std::filesystem::is_regular_file(p)) {
std::filesystem::remove(p);
return;
}
for (auto& entry : std::filesystem::directory_iterator(p))
remove_recursive(entry.path());
std::filesystem::remove(p); // 空了才删目录
}
跨平台健壮删除要考虑的三个隐藏细节
实际工程中，单纯的删除操作往往失败，核心干扰来自三类系统级约束：
- Windows 下，
std::filesystem::remove_all无法删除正在被其他进程打开的句柄（比如记事本打开的 txt 文件），即使只是读打开也不行。需要提前关闭或者提示用户 - 某些杀毒软件会劫持文件删除 API，导致
filesystem_error中的 error_code 为access_denied，但并非权限问题。此时重试加延迟可能有效 - 长路径（超过 260 字符）在 Windows 默认禁用，需要启用长路径支持（注册表或清单文件），否则
remove_all直接失败
真正难的从来不是写几行递归代码，而是判断失败原因属于哪一层——是应用层权限？系统句柄占用？还是反病毒干预？查错时优先看 filesystem_error::code().value()，而不是只读报错字符串。
