基本一致，但Windows不递归删符号链接目标且可能静默失败只读文件，Linux则会递归并抛异常；需C++17支持、正确链接（如Windows加Shlwapi.lib）、用path构造路径并检查存在性。
std::filesystem::remove_all 在 Windows 和 Linux 下行为一致吗？
基本一致，但要注意权限和符号链接的处理差异。Windows 默认不递归删除符号链接指向的目标，而 Linux 会；如果目标是只读文件，remove_all 在 Windows 上可能静默失败（不抛异常），Linux 则通常抛 std::filesystem::filesystem_error。
- 必须在编译时启用 C++17（如
g++ -std=c++17或 MSVC /std:c++17） - 需包含头文件：
#include <filesystem></filesystem>，并注意 MSVC 还需链接Shlwapi.lib - 路径参数建议用
std::filesystem::path构造，避免裸字符串中的反斜杠转义问题（如R"(C:\temp\cache)"或"C:/temp/cache"） - 调用前最好先检查路径存在且可访问：
exists(p) && is_directory(p)，否则remove_all对不存在路径返回 0，不报错也不提示
为什么 remove_all 后目录还残留、或抛 filesystem_error？
常见原因是当前进程或另一程序正占用该目录下的某个文件（比如日志被打开、IDE 正在索引、防病毒软件扫描中）。remove_all 是原子性递归删除，只要中途遇到一个无法删除的项（权限不足、忙、只读），就立即抛出异常，不会继续尝试后续项。
- Windows 下典型错误信息：
Permission denied或The process cannot access the file because it is being used by another process - Linux 下常见：
Device or resource busy（如挂载点）、Operation not permitted（SELinux 或 cap_sys_admin 限制） - 不要依赖
remove_all的返回值判断成功与否——它返回std::uintmax_t删除项数，但失败时直接抛异常，不返回 - 若需“尽力清理”，应手动遍历 + try/catch 单个
remove，而不是依赖remove_all
替代方案：自己写跨平台递归删除，比 remove_all 更可控？
是的，尤其当你要跳过特定子目录（如 .git）、保留空目录结构、或记录哪些文件删失败时。remove_all 是“全有或全无”，而手动遍历能插入手动逻辑。
- 用
std::filesystem::recursive_directory_iterator逆序遍历（从深到浅），再逐个remove，可避免“目录非空无法删”的问题 - 对每个
entry，先判断is_regular_file(entry)或is_directory_entry(entry)再操作，避免误删符号链接本身（而非其目标） - Linux 下若想跳过符号链接目标，加
std::filesystem::symlink_option::no_recurse参数；Windows 不支持该选项，需自行!is_symlink(entry)过滤 - 示例关键逻辑：
for (auto it = std::filesystem::recursive_directory_iterator(path, std::filesystem::directory_options::skip_permission_denied); it != std::filesystem::end(it); ++it) { try { std::filesystem::remove(it->path()); } catch (...) { /* 记录失败路径 */ } }
MSVC 2019/2022 中 _remove_all 编译失败或链接失败？
不是标准函数名——C++17 标准里只有 std::filesystem::remove_all，没有下划线前缀的 _remove_all。如果你看到这个写法，大概率是混用了旧版 Boost.Filesystem 或某封装库的宏定义，或是误抄了 POSIX 的 remove() 行为。
立即学习“C++免费学习笔记（深入）”；
- 确认你调用的是
std::filesystem::remove_all(path)，不是::_remove_all或boost::filesystem::remove_all - MSVC 需显式启用文件系统支持：项目属性 → C/C++ → 语言 → “启用 C++17 标准” + 确保“使用标准符合模式”未强制关闭
std::filesystem - 链接错误 LNK2019 常见于没加
Shlwapi.lib（仅 Windows）；CMake 用户需加target_link_libraries(myapp Shlwapi) - Clang on Windows（如 clang-cl）同样需要
Shlwapi.lib；GCC on Linux 不需要额外链接
实际跨平台清理最麻烦的从来不是 API 调用，而是目录正在被别的进程锁着——哪怕只是 shell 当前工作目录设在了那里。别迷信 remove_all 万能，真要稳健，得配合重试、权限修复、进程检查一起上。
