std::filesystem::remove_all会递归删除整个目录树，包括目标目录本身及所有内容，不区分空或非空；需C++17支持、路径存在且权限足够，返回删除项数，失败时可能返回0或抛filesystem_error。
std::filesystem::remove_all 会递归删除整个目录树
这个函数不是只删空目录，而是彻底清空目标路径下所有文件和子目录，包括目标目录本身。只要权限足够且路径存在，它就会一路删到底，不需要你手动遍历或先清空再删目录。
常见错误现象：std::filesystem::remove_all 返回 false 却没报错，其实是路径不存在或无访问权限；更隐蔽的是遇到只读文件时，在 Windows 上可能静默失败（不抛异常但返回 false），Linux 下通常会抛 std::filesystem::filesystem_error。
- 必须开启 C++17 或更高标准（编译时加
-std=c++17） - 需要链接
-lstdc++fs（GCC 早期版本，如 GCC 8/9；GCC 10+ 和 Clang 通常自动处理） - 路径参数可以是
std::filesystem::path或字符串字面量，推荐用std::filesystem::path避免编码歧义
如何安全调用 remove_all 并捕获错误
直接裸调用容易掩盖问题，尤其在自动化脚本或部署逻辑中。你应该显式检查返回值，并用 try/catch 捕获底层系统错误。
try {
auto count = std::filesystem::remove_all("/tmp/my_project");
if (count == 0) {
// 路径不存在，或不是目录/文件（比如是符号链接且指向无效路径）
} else {
// 成功删除了 count 个文件/目录项
}
} catch (const std::filesystem::filesystem_error& ex) {
// ex.code() 给出具体 errno，ex.what() 含路径和错误描述
// 例如：permission denied, "xxx", Permission denied
}
- 返回值是
std::uintmax_t：成功时为删除的总项数（含目标目录自身）；失败时为 0 - 不要依赖返回值非零就认为“全部删完”——中间某一项失败会导致提前终止，但已删的部分不会回滚
- Windows 下对正在被其他进程占用的文件，会直接失败；Linux 下同理，但某些情况（如 mmap 映射的文件）行为更严格
remove_all 在跨平台场景下的关键差异
同一段代码在 Windows 和 Linux 上可能表现不同，主要源于底层 API 行为和权限模型差异。
立即学习“C++免费学习笔记（深入）”；
- Windows 不区分“执行权限”，但要求目录可写才能删除；Linux 则依赖父目录的写+执行权限（即“sticky bit”不影响，但父目录不可写就删不掉子项）
- 符号链接：默认情况下
remove_all会解引用并删除目标内容（类似rm -rf），不是删链接本身；若想只删链接，得先用is_symlink()判断再调用remove() - 长路径（>260 字符）在 Windows 默认 ANSI API 下会失败；启用 UTF-8 模式（
SetConsoleOutputCP(CP_UTF8)+ 编译选项）或使用\?前缀可缓解，但std::filesystem通常已内部处理 Unicode 路径
替代方案：什么时候不该用 remove_all
如果你只需要清理内容、保留空目录，或者要跳过特定子目录（比如 .git）、保留某些文件类型，remove_all 就太粗暴了。
- 要保留目录结构？改用
std::filesystem::recursive_directory_iterator手动遍历 + 条件过滤 - 担心误删？先用
std::filesystem::exists()和std::filesystem::is_directory()双重校验路径 - 需要原子性或回滚能力？C++ 标准库不提供，得自己实现临时重命名 + 异步清理，或依赖外部工具（如
rsync --delete配合快照）
最常被忽略的一点：remove_all 不等价于 shell 的 rm -rf 在所有边缘情况下——比如挂载点、设备文件、proc/sysfs 路径，它可能抛异常或静默失败，而这些恰恰是 CI/CD 或容器环境中容易踩的坑。
