优先使用 std::filesystem，因其自 C++17 起已标准化、编译器支持良好、无需额外依赖且 ABI 稳定；仅当必须支持 C++14 或需 Boost 独有扩展功能时才考虑 Boost.Filesystem。
直接用 std::filesystem，除非你卡在 C++14 或更早、或必须兼容某些不支持它的旧编译器。
标准库已覆盖绝大多数需求
std::filesystem（C++17 引入）不是 Boost.Filesystem 的简化版，而是以它为蓝本标准化的结果。路径拼接、遍历目录、判断文件类型、创建/删除/重命名、获取大小与时间戳等核心功能完全一致，接口设计也高度相似——比如 fs::path、fs::exists()、fs::recursive_directory_iterator 都能直接对应上。
- 编译器支持良好：GCC 8+、Clang 7+、MSVC 2017 15.9+ 均已完整支持
- 无需额外依赖：不用下载、编译、链接 Boost，减少构建复杂度和部署体积
- ABI 稳定：标准库由编译器提供，不会因 Boost 版本升级引发二进制不兼容
Boost.Filesystem 还值得用吗？
仅在两种情况下考虑：
- 项目必须支持 C++11/C++14，且无法升级标准版本
- 需要 Boost.Filesystem 独有的扩展功能（如某些平台特定的权限控制、符号链接解析策略），但这类需求极少见
注意：Boost 1.70+ 已将 boost::filesystem 内部切换为调用 std::filesystem（若可用），实际行为趋于一致，进一步削弱了独立使用的必要性。
迁移成本很低，别被“改头换面”吓到
从 Boost 切到 std::filesystem 通常只需三步：
- 头文件从
- 命名空间从
boost::filesystem改为std::filesystem（或加using namespace std::filesystem;） - 链接项去掉
-lboost_filesystem，C++17 下通常无需额外链接（个别旧 GCC 可能需-lstdc++fs）
函数名、参数顺序、异常行为基本不变，现有逻辑几乎不用改。
一个现实提醒：Windows 路径分隔符和 Unicode
两者在 Windows 下都默认支持宽字符路径（std::wstring 构造 path），能正确处理中文路径和长路径（需程序 manifest 配置）。但 std::filesystem 对 UTF-8 字节串的支持更明确（C++20 起强化），而老版本 Boost 在某些 MinGW
配置下偶有编码歧义——如果你的项目要跨平台且含非 ASCII 路径，std::filesystem 反而更省心。
基本上就这些。标准库有了，就别绕远路了。
