会，std::filesystem::remove_all 会误删且不可恢复：它递归删除整个路径下所有内容，常见错误包括传入".."或相对路径导致误删、符号链接指向目录时仍删除目标内容、Windows权限不足时静默失败等，务必用绝对路径、检查目录存在性、验证返回值。
std::filesystem::remove_all 会删错东西吗？
会，而且删得非常彻底——它不区分“空”或“非空”，也不管你有没有写权限、路径是否符号链接指向别处，只要调用成功，整个路径下所有内容（包括子目录、只读文件、隐藏文件）全被递归删除，且不可恢复。
常见错误现象：std::filesystem::remove_all("build") 在 CI 脚本里误写成 std::filesystem::remove_all("..")，直接清空上层项目目录；或者传入相对路径但当前工作目录意外变更，导致误删。
- 务必确保传入的是绝对路径：用
std::filesystem::absolute(path)包一层再删 - 提前检查路径是否存在且是目录：
std::filesystem::is_directory(p)，避免对普通文件调用后静默失败（C++20 起返回 false，但旧实现可能抛异常） - 若路径含符号链接，默认只删链接本身（不跟随），但若链接指向目录，
remove_all仍会进入并删除目标目录内容——这点极易被忽略
Windows 下权限不足时为什么没报错？
因为 std::filesystem::remove_all 在 Windows 上对只读文件默认尝试先清除只读属性再删除；若失败（如无管理员权限删系统目录），它不会立即 throw，而是跳过该条目继续删其余内容，最终返回 false —— 但很多人只看返回值不检查，以为删干净了。
使用场景：清理构建产物时，build/obj/ 下某些 .obj 文件被编译器进程锁住，或 build/CMakeCache.txt 被设为只读。
- 删前建议先用
std::filesystem::permissions(p, std::filesystem::perms::owner_write)强制加写权限（注意：仅对当前用户有效） - 必须检查返回值：
if (!std::filesystem::remove_all(p)) { /* 至少有一个删失败 */ } - 不要依赖异常判断成败：标准规定它只在“路径格式非法”或“无法访问父目录”等严重情况才 throw
std::filesystem::filesystem_error，权限问题通常静默失败
替代方案：自己写递归删除更安全吗？
不更安全，反而更容易出错。手写容易漏掉符号链接循环、权限处理不一致、跨平台路径分隔符混淆，还可能因未按逆序遍历导致“目录非空”错误中断。
性能影响：标准库的 remove_all 在 Linux 下用 unlinkat(AT_REMOVEDIR) 系统调用，比逐个 remove + rmdir 快；Windows 下也做了批处理优化。
- 真要可控，可用
std::filesystem::recursive_directory_iterator遍历，但删的时候必须从深到浅（用std::vector缓存路径后倒序删） - 若需跳过特定子目录（如
.git），remove_all不支持过滤，只能手写遍历 + 条件判断 - 注意 C++17 实现差异：MSVC 19.2x 对长路径支持弱，
remove_all可能截断；GCC 10+ 和 Clang 12+ 更稳定
CI/CD 脚本里怎么防手抖？
核心不是换函数，而是加约束：把删除行为变成“可审查、可拦截、可回滚”的操作。
常见错误现象：GitHub Actions YAML 里写 run: rm -rf ${{ github.workspace }}/build，但 github.workspace 在自托管 runner 上可能指向根目录。
- 在 C++ 代码中删前打印绝对路径：
std::cout - 开发期加预检查宏：
#ifdef DEBUG_REMOVE\n if (p.filename() == "build") abort(); // 临时熔断\n#endif - CI 中改用带 dry-run 的封装脚本，比如先
find build -mindepth 1 | head -20看范围，确认后再执行
最麻烦的点其实不在函数本身，而在于路径来源不可信——环境变量、命令行参数、配置文件里的路径，几乎每个都可能被污染。盯住输入，比研究怎么删更重要。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
