std::filesystem::remove_all是c++17首选递归删除方案，需编译器支持（gcc 8+/clang 7+/msvc 2017 15.7+），注意权限、路径存在性、进程占用等异常原因，返回删除总数或抛出filesystem_error。
用 std::filesystem::remove_all 最直接，但得先确认 C++17 支持
如果你的编译器支持 C++17（GCC 8+、Clang 7+、MSVC 2017 15.7+），std::filesystem::remove_all 就是首选。它递归删除目录及其所有内容，语义清晰，跨平台，不用自己遍历。
常见错误现象：std::filesystem::remove_all 报 std::filesystem::filesystem_error，多数是因为权限不足、路径不存在、或目录被其他进程占用（比如资源管理器正打开该文件夹）。
- 必须加
#include <filesystem></filesystem>，且 GCC/Clang 需链接-lstdc++fs（MSVC 默认支持） - 路径参数必须是
std::filesystem::path类型，传裸字符串会隐式转换，但建议显式构造：std::filesystem::path("my_dir") - 返回值是
std::uintmax_t：成功时为删除的文件/目录总数；失败时抛异常，不返回 0 - 不会删除挂载点（如 Windows 下的符号链接目标目录）、也不会跳过只读文件——但只读文件在 Windows 上删不掉，会抛异常
try {
std::uintmax_t n = std::filesystem::remove_all("build/");
std::cout <h3>Windows 下用 <code>SHFileOperation</code> 或 <code>RemoveDirectory</code>？别轻易碰</h3><p>老项目或需要精细控制时有人想用 Win32 API，但实际很危险：这些函数不递归，<code>RemoveDirectory</code> 要求目录为空，否则直接失败；<code>SHFileOperation</code> 是 Shell 级 API，行为受系统策略影响（比如回收站设置、UAC 提示），且 C++ 标准库已提供更稳的替代。</p><p>使用场景极少：仅当你明确要模拟“移到回收站”或需 UI 进度反馈时才考虑 <code>SHFileOperation</code>；纯后台删除请绕开。</p>
-
RemoveDirectory对非空目录返回FALSE，GetLastError()是ERROR_DIR_NOT_EMPTY，不是崩溃，但容易误判为“删成功了” -
SHFileOperation的fFlags若漏设FOF_NOCONFIRMATION | FOF_SILENT，会在无 GUI 环境卡死 - 两者都不处理 UTF-8 路径（Windows API 原生用 UTF-16），而
std::filesystem::path自动处理编码转换
Linux/macOS 下 system("rm -rf") 是最差选择
用 system("rm -rf ...") 看似简单，但有严重隐患：路径含空格、$、`、* 等 shell 元字符时会执行任意命令；无法捕获具体失败原因（比如某个子文件权限拒绝）；完全绕过 C++ 异常和错误处理机制。
性能上没优势，兼容性反而更差（macOS 的 rm 和 BusyBox 的行为略有差异）。
- 哪怕只是临时脚本，也应优先用
std::filesystem::remove_all - 若真要调用
rm，必须对路径做 shell 转义（比如单引号包裹 + 内部单引号替换），工程成本远超引入filesystem -
std::filesystem::remove_all在 Linux 下底层调用unlinkat(AT_REMOVEDIR)和unlink，比 fork+execrm更轻量
删除前务必检查路径合法性与权限
std::filesystem::remove_all 不会阻止你删系统目录（如 "/" 或 "C:\"），也不会校验是否为相对路径陷阱（如 "../etc"）。这属于业务逻辑责任，不是标准库该管的。
容易踩的坑：开发时用 "./temp" 测试没问题，上线后配置错成 "../"，导致整个部署目录被清空。
- 用
std::filesystem::is_absolute(path)拦截绝对路径（除非你明确需要） - 用
std::filesystem::canonical(path)展开..和符号链接，再判断是否在允许根目录下（例如白名单前缀/home/user/app/） - Linux/macOS 下可提前用
access(path.c_str(), W_OK)检查写权限；Windows 下此检查不可靠，仍需依赖remove_all的异常 - 调试时加日志输出将删的路径（注意脱敏，避免打印敏感路径）
实际项目里，95% 的目录删除需求用 std::filesystem::remove_all 加路径校验就够了。真正麻烦的是那些没被日志记录的静默失败——比如 NFS 挂载点突然不可写，或者容器里 /tmp 权限被锁死，这时候异常类型和 what() 里的系统错误码就是唯一线索。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
