C++17的std::filesystem是最稳妥跨平台方案，需启用C++17标准、显式链接库（GCC加-lstdc++fs，MSVC开箱即用），注意路径编码安全、符号链接处理、remove_all错误码检查及异常码为POSIX值。
直接上结论：C++17 的 std::filesystem 是目前最稳妥、跨平台（MSVC/GCC/Clang 均已完整支持）的本地文件系统操作方案，但必须显式链接 -lstdc++fs（GCC）、启用 C++17 标准，且路径对象生命周期管理稍不注意就会引发未定义行为。
如何正确启用并验证 std::filesystem
很多编译失败根本不是代码问题，而是构建配置没到位：
- 编译器需明确指定
-std=c++17（Clang/GCC）或/std:c++17（MSVC） - GCC 9.1+ 默认仍不自动链接
std::filesystem实现，必须加-lstdc++fs；GCC 11+ 可改用-lstdc++，但显式写-lstdc++fs更清晰 - MSVC 2017 Update 5+ 开箱即用，但需确保项目属性中“C++ 语言标准”设为 ISO C++17 标准
- 运行时若报
undefined reference to 'std::filesystem::u8path'，基本就是忘了加链接库
path 对象不能裸传 const char*
std::filesystem::path 构造函数接受 const char*，但底层会按当前 locale 解码——这在中文 Windows 或 UTF-8 终端下极易出错。更安全的做法是：
- 始终用
u8"xxx"字符串字面量构造路径：fs::path p{u8"/home/用户/文档"} - 读取外部字符串（如命令行参数、配置文件）时，先转成
std::u8string再构造：fs::path{std::u8string{argv[1]}} - 避免对
path.c_str()做指针保存：其返回值生命周期仅限于该次调用，后续再用就是悬垂指针
exists() 和 status() 别混用，尤其要防 symlink 循环
exists(p) 是常用判断，但它内部调用 status(p) 并检查是否为 file_not_found。真正要注意的是：
立即学习“C++免费学习笔记（深入）”；
- 对符号链接默认会解引用（dereference），如果链向自身或形成环，
exists()可能抛出filesystem_error异常（错误码std::errc::too_many_symbolic_link_levels） - 想安全判断链接本身是否存在，用
exists(p, ec)（带错误码重载）或status(p, ec)+ec.clear() - 批量遍历时，
directory_iterator默认也解引用 symlink，如需跳过，构造时传fs::directory_options::skip_permission_denied不起作用，得手动过滤is_symlink(it->status())
remove_all() 的静默失败陷阱
fs::remove_all(p) 看似强大，但它在遇到权限不足或正在使用的文件时，默认直接返回 0（删除数），不抛异常也不设错误码——你可能以为删干净了，其实什么都没动。
- 务必配合错误码使用：
fs::remove_all(p, ec)，之后检查ec是否非零 - Windows 下删除非空只读目录（如
.git）会失败，需先递归设置fs::permissions(p, fs::perms::owner_write, fs::perm_options::add) - Linux 下若某子目录被
chroot或挂载覆盖，remove_all可能只删到挂载点就停，不会报错
最易被忽略的一点：所有 std::filesystem 函数抛出的异常类型是 std::filesystem::filesystem_error，它继承自 std::system_error，但其 .code().value() 返回的是 POSIX 错误码（如 2 = ENOENT），不是 Windows GetLastError() 值——跨平台日志里别直接 printf("%d") 打印它。
