1. 项目概述：为什么我们需要一个现代的文件系统库？

如果你用C++写过一些需要处理本地文件的程序，比如一个日志分析工具、一个配置文件管理器，或者一个简单的资源打包器，那你肯定没少和<fstream>、<dirent.h>或者Windows的FindFirstFile打交道。这些传统的API用起来是什么感觉？繁琐、平台依赖、错误处理麻烦。你要打开一个文件，得先检查路径是否存在，是文件还是目录，权限够不够，每一步都可能失败，每一行代码都写着“平台特定”几个字。更别提遍历一个目录了，那代码量，写起来都觉得自己在造轮子，而且还是方形的。

这就是std::filesystem（文件系统库）被引入C++17标准库的核心原因。它不是一个新发明，而是把Boost.Filesystem这个久经考验的库标准化了，旨在为C++程序员提供一个统一、类型安全、异常安全的方式来操作文件和目录。简单说，它把那些跨平台的、脏活累活都封装好了，给你一套简洁的、现代C++风格的接口。你再也不用为了遍历一个文件夹，在Windows上写一套WIN32_FIND_DATA，在Linux上又写一套struct dirent了。一个std::filesystem::directory_iterator走天下。

这个库的价值远不止于“写起来方便”。在当今软件复杂度的背景下，可靠的路径处理、递归文件操作、空间查询等都是基础需求。无论是开发桌面应用、服务器后端、游戏引擎还是构建工具，文件系统操作都是绕不开的一环。std::filesystem的出现，意味着C++在系统级编程的现代化道路上，补上了一块至关重要的拼图。它让我们的代码更健壮（更好的错误处理）、更清晰（语义明确的函数名）、更易于移植（标准保证的行为）。

2. 核心概念与路径解析

在深入具体操作之前，我们必须先理解std::filesystem的基石：std::filesystem::path类。几乎所有文件系统操作都始于一个路径对象。

2.1std::filesystem::path：不仅仅是字符串

路径不是字符串。这是一个非常重要的观念转变。一个path对象内部存储的是操作系统原生格式的路径（在Windows上是宽字符，在POSIX上是窄字符），但它提供了一系列成员函数来以可移植的方式分解和检查路径。

#include <filesystem> namespace fs = std::filesystem; // 常用的命名空间别名 fs::path p1 = "C:\\Users\\Name\\Documents\\file.txt"; // Windows 风格 fs::path p2 = "/home/name/docs/file.txt"; // POSIX 风格 fs::path p3 = R"(project\src\main.cpp)"; // 原始字符串，避免转义

为什么用path而不用std::string？

1. 可移植性：path的/运算符重载能自动处理路径分隔符。p3 / "include" / "header.h"在Windows上生成project\src\main.cpp\include\header.h，在Linux上生成project/src/main.cpp/include/header.h。你用字符串拼接还得自己判断平台。
2. 分解能力：你可以轻松获取路径的各个部分。

   fs::path p = "/home/user/project/src/main.cpp"; std::cout << p.root_name() << '\n'; // 在Linux上通常是空，在Windows上可能是“C:” std::cout << p.root_directory() << '\n'; // “/” std::cout << p.parent_path() << '\n'; // “/home/user/project/src” std::cout << p.filename() << '\n'; // “main.cpp” std::cout << p.stem() << '\n'; // “main” (不带扩展名) std::cout << p.extension() << '\n'; // “.cpp”

3. 隐式转换：path可以隐式转换为std::string（或std::wstring），方便传递给需要字符串的老API，但核心操作应始终使用path对象。

注意：path的构造函数和赋值操作不会检查路径在文件系统中是否存在。它只是一个路径的“描述符”。存在性检查是后续操作（如fs::exists）的事情。

2.2 路径的规范化和弱规范化

这是路径处理中一个容易踩坑的地方。path对象可以进行规范化（lexically_normal）和弱规范化（lexically_relative,lexically_proximate）。

• lexically_normal()：移除路径中的.（当前目录）和..（上级目录）引用，并简化多余的斜杠。这是一个纯词法操作，不访问文件系统。

  fs::path p = "a/./b/../c/"; std::cout << p.lexically_normal() << '\n'; // 输出 “a/c/”

  这非常有用，特别是在处理用户输入或配置文件中的路径时，可以避免一些因路径格式混乱导致的问题。

• lexically_relative(base)：计算当前路径相对于另一个路径base的词法相对路径。同样不访问文件系统。如果两个路径没有共同的前缀，则返回空路径。

  fs::path p = "/a/b/c"; fs::path base = "/a/d"; std::cout << p.lexically_relative(base) << '\n'; // 输出 “../b/c”

  这在生成相对于项目根目录的路径时特别有用。

• relative(path, base)和proximate(path, base)：这是两个文件系统操作（需要路径真实存在）。它们尝试返回一个相对于base的路径。区别在于，当无法计算相对路径时（例如在不同驱动器上），relative会抛出异常或返回错误，而proximate会返回输入的绝对路径。通常proximate更安全。

实操心得：在拼接或比较路径前，尤其是当路径来源不可控时（如用户输入），先进行lexically_normal()是一个好习惯。这能消除很多潜在的歧义。对于需要真实文件系统关系的相对路径计算，优先考虑使用proximate。

3. 文件与目录的查询与属性获取

知道了路径，下一步就是了解它指向的“东西”。std::filesystem提供了一套丰富的函数来查询文件状态和属性。

3.1 存在性与类型判断

这是最基本的操作，通常是你进行任何其他操作前的安全检查。

fs::path p = "some_file.txt"; // 检查是否存在 if (fs::exists(p)) { std::cout << "Path exists.\n"; } // 检查是普通文件还是目录 if (fs::is_regular_file(p)) { std::cout << "It's a regular file.\n"; std::cout << "File size: " << fs::file_size(p) << " bytes.\n"; // 获取文件大小 } else if (fs::is_directory(p)) { std::cout << "It's a directory.\n"; } // 其他类型判断 if (fs::is_symlink(p)) { /* 符号链接 */ } if (fs::is_block_file(p)) { /* 块设备 */ } // ... 还有 is_character_file, is_fifo, is_socket 等

file_size的坑：file_size只对普通文件（is_regular_file）和符号链接（指向普通文件）有效。对目录、设备文件等调用file_size会导致错误。最佳实践是，在调用file_size前，务必用is_regular_file检查一下，或者准备好处理可能抛出的filesystem_error异常。

3.2 获取详细状态：file_status和symlink_status

status(path)和symlink_status(path)函数返回一个file_status对象，它封装了文件类型和权限信息。两者的区别在于对待符号链接的方式：status会跟随（解引用）符号链接，返回链接目标的状态；而symlink_status返回符号链接本身的状态。

fs::file_status st = fs::status(p); fs::perms perm = st.permissions(); // 获取权限 // 检查权限 (使用位掩码) using fs::perms; if ((perm & perms::owner_read) != perms::none) { std::cout << "Owner can read.\n"; } if ((perm & perms::group_write) == perms::none) { std::cout << "Group cannot write.\n"; } // 检查文件类型 switch (st.type()) { case fs::file_type::regular: /*...*/ break; case fs::file_type::directory: /*...*/ break; case fs::file_type::symlink: /*...*/ break; case fs::file_type::none: case fs::file_type::not_found: std::cout << "File does not exist or cannot be accessed.\n"; break; // ... 其他类型 }

为什么关心symlink_status？在处理可能包含符号链接的目录树时，区分链接本身和链接目标至关重要。例如，在复制目录时，你可能想保留符号链接（复制链接本身），而不是复制它指向的整个目标（这可能造成循环或数据冗余）。这时就需要用symlink_status来判断原始条目是否为链接。

3.3 其他有用信息：最后修改时间与空间信息

• 最后修改时间：fs::last_write_time(p)返回一个file_time_type（通常是std::chrono::time_point）。你可以用它来做增量备份、缓存失效判断等。

  auto ftime = fs::last_write_time(p); // 可以转换为 time_t 以便使用C库函数打印 auto sctp = std::chrono::time_point_cast<std::chrono::system_clock::duration>(ftime - fs::file_time_type::clock::now() + std::chrono::system_clock::now()); std::time_t tt = std::chrono::system_clock::to_time_t(sctp); std::cout << "Last modified: " << std::ctime(&tt);

  注意：修改文件时间本身也是可以的，使用fs::last_write_time(p, new_time)。

• 空间信息：fs::space(p)返回一个space_info结构体，包含该路径所在磁盘的总容量、空闲空间和可用空间。

  fs::space_info si = fs::space("/"); std::cout << "Total: " << si.capacity << " bytes\n" << "Free: " << si.free << " bytes\n" << "Available: " << si.available << " bytes\n";

  在写入大文件或做数据备份前，检查磁盘空间是一个很好的防御性编程习惯。

4. 目录遍历：迭代器的艺术

遍历目录是文件系统操作中最常见的任务之一。std::filesystem提供了两种主要的迭代器：directory_iterator和recursive_directory_iterator。

4.1directory_iterator：单层遍历

它用于遍历一个目录下的直接子项（文件和子目录），不会进入子目录。

fs::path dir_path = "./test_dir"; try { for (const auto& entry : fs::directory_iterator(dir_path)) { const auto& path = entry.path(); std::cout << "Found: " << path.filename() << " -> "; if (entry.is_regular_file()) { std::cout << "File, size: " << entry.file_size() << '\n'; } else if (entry.is_directory()) { std::cout << "Directory\n"; } else if (entry.is_symlink()) { std::cout << "Symlink\n"; // entry.symlink_status() 获取链接本身状态 // fs::read_symlink(path) 读取链接目标 } // entry 还有 status(), path(), file_size() 等方法，非常方便 } } catch (const fs::filesystem_error& e) { std::cerr << "Directory iteration error: " << e.what() << '\n'; }

directory_entry对象（即迭代器解引用得到的entry）缓存了文件状态信息，这意味着多次调用entry.is_regular_file()或entry.file_size()是高效的，不会重复进行昂贵的系统调用。

4.2recursive_directory_iterator：递归遍历

顾名思义，它会递归地遍历目录树。这是实现“查找所有某种文件”功能的利器。

fs::path root_path = "./project"; try { for (const auto& entry : fs::recursive_directory_iterator(root_path)) { // 可以在这里进行过滤 if (entry.is_regular_file() && entry.path().extension() == ".cpp") { std::cout << "C++ source: " << entry.path() << '\n'; } // 控制递归深度和是否跟随符号链接 // 默认深度无限制，默认不跟随符号链接（防止循环） } } catch (const fs::filesystem_error& e) { std::cerr << "Recursive iteration error: " << e.what() << '\n'; }

高级控制：recursive_directory_iterator可以通过构造函数选项进行精细控制。

// 选项枚举 using fs::directory_options; auto options = directory_options::skip_permission_denied // 跳过无权限目录 | directory_options::follow_directory_symlink; // 跟随目录符号链接（危险！） fs::recursive_directory_iterator it(root_path, options); // 在遍历过程中，还可以动态控制 for (; it != fs::recursive_directory_iterator(); ++it) { if (it->path().filename() == "build") { it.disable_recursion_pending(); // 不进入名为“build”的目录 } if (it.depth() > 5) { // 限制递归深度 it.pop(); // 跳出当前目录，继续遍历同级或上级 } }

重要警告：follow_directory_symlink选项非常危险！如果目录树中存在符号链接环（A链接到B，B又链接回A），启用此选项会导致迭代器陷入无限循环，直到耗尽内存或达到路径长度限制。除非你百分百确定目录树中没有循环链接，否则不要使用这个选项。一个更安全的做法是默认不跟随，当遇到符号链接时，手动调用fs::read_symlink判断目标，再决定是否进行特殊处理。

4.3 遍历中的性能与错误处理

遍历大型目录树（如整个硬盘）是I/O密集型操作，可能很慢，并且会遇到各种权限问题。

• 性能：directory_entry缓存了状态，所以尽量使用entry的方法（如is_...,file_size），而不是重新调用fs::status(entry.path())。
• 错误处理：迭代器在遍历时，如果遇到一个无法访问的子目录（如权限不足），默认行为是抛出filesystem_error异常。这会导致整个遍历中断。为了避免这种情况，可以使用directory_options::skip_permission_denied选项，让迭代器静默跳过这些目录。你需要在构造迭代器时指定这个选项。
• 迭代器失效：在遍历过程中，如果其他进程或线程修改了正在遍历的目录结构（如删除或创建文件），可能会导致迭代器失效或行为未定义。对于关键应用，可以考虑先收集路径列表，再进行处理。

5. 文件与目录的操作：创建、复制、移动与删除

查询和遍历是“读”操作，而std::filesystem同样提供了完整的“写”操作。

5.1 创建目录

创建单个目录或多个层级的目录。

fs::path new_dir = "new_folder"; fs::path deep_dir = "a/b/c/d/e"; // 创建单个目录。如果父目录不存在，则失败。 if (!fs::create_directory(new_dir)) { std::cout << "Directory already exists or creation failed.\n"; } // 递归创建目录（类似于 mkdir -p）。如果目录已存在，也不会报错。 bool created = fs::create_directories(deep_dir);

create_directories是原子性的吗？不完全是。虽然它试图创建路径上的所有目录，但如果中间某一步失败（例如，在创建a/b后，另一个进程创建了a/b/c作为一个文件），那么函数会失败并可能留下部分创建的目录。通常你需要处理filesystem_error异常。

5.2 复制文件与目录

复制操作功能强大，可以通过copy_options进行精细控制。

fs::path src = "source.txt"; fs::path dst = "backup/source_copy.txt"; // 最简单的复制文件 fs::copy(src, dst); // 如果dst已存在，默认会抛出异常 (copy_options::none) // 使用选项 using fs::copy_options; auto options = copy_options::overwrite_existing // 覆盖已存在文件 | copy_options::recursive // 如果是目录，递归复制 | copy_options::copy_symlinks; // 复制符号链接本身，而不是其目标 fs::copy(src, dst, options); // 专门复制目录（需要 recursive 选项） fs::path src_dir = "data"; fs::path dst_dir = "backup/data"; fs::copy(src_dir, dst_dir, copy_options::recursive | copy_options::overwrite_existing);

copy_options详解：

• overwrite_existing：覆盖目标路径已存在的文件。
• skip_existing：跳过已存在的文件。
• update_existing：仅当源文件比目标文件新时覆盖。
• recursive：递归复制子目录和内容。
• copy_symlinks：复制符号链接为符号链接。
• skip_symlinks：忽略符号链接。
• directories_only：只复制目录结构，不复制文件内容。
• create_symlinks/create_hard_links：创建指向源文件的符号链接或硬链接，而不是复制内容。

重要提示：fs::copy在复制单个文件时，默认不会复制文件的最后修改时间等属性。如果需要保留所有属性（类似于cp -p），需要使用copy_options::preserve_all，它等价于copy_symlinks | copy_directory | preserve_all，会保留权限、时间戳等。

5.3 移动与重命名

移动和重命名在文件系统层面是同一个操作：改变文件或目录的路径。

fs::path old_name = "old.txt"; fs::path new_name = "new.txt"; fs::path new_location = "subdir/new.txt"; // 重命名文件 fs::rename(old_name, new_name); // 如果new_name已存在，行为由操作系统决定，通常失败或覆盖。 // 移动文件到另一个目录（并可能重命名） fs::rename("file.txt", "another_dir/file.txt"); // 跨设备/分区移动？ // fs::rename 要求源和目标必须在同一个文件系统（挂载点）上。 // 如果跨设备，rename会失败。此时需要先复制再删除。 if (!fs::rename(src, dst)) { // 如果rename失败，可能是因为跨设备 fs::copy(src, dst, fs::copy_options::overwrite_existing | fs::copy_options::recursive); fs::remove_all(src); // 小心使用！ }

fs::rename是原子操作（在同一个文件系统内）。如果目标已存在，其行为是操作系统定义的。在POSIX系统上，如果目标是已存在的文件，它会被静默替换；如果是已存在的非空目录，操作会失败。在Windows上，如果目标已存在，rename通常会失败。为了可移植的“覆盖”行为，你应该先检查并删除目标（如果存在且允许覆盖），然后再调用rename。

5.4 删除文件与目录

删除操作需要格外小心，尤其是递归删除。

fs::path file_to_remove = "temp.txt"; fs::path dir_to_remove = "temp_dir"; // 删除单个文件或空目录 bool removed = fs::remove(file_to_remove); // 返回是否真的删除了东西 if (!removed) { std::cout << "File did not exist.\n"; } // 递归删除目录及其所有内容 (类似于 rm -rf) std::uintmax_t num_removed = fs::remove_all(dir_to_remove); std::cout << "Removed " << num_removed << " files/directories.\n";

remove_all的巨坑与最佳实践：fs::remove_all功能强大，但也极其危险。一旦执行，数据几乎无法恢复（除非有备份）。我亲身踩过的坑：在写一个清理临时文件的脚本时，因为一个路径构造错误，差点把项目源码目录给删了。

安全准则：

1. 绝对不要对用户输入的路径直接使用remove_all。必须先进行严格的验证和规范化。
2. 在调用remove_all之前，先打印出要删除的路径，或者要求二次确认。在调试版本中可以加入此逻辑。
3. 考虑使用fs::canonical或fs::weakly_canonical。它们能返回一个绝对且规范化的路径，消除.和..的影响，并解析符号链接（canonical要求路径必须存在）。这有助于避免因路径歧义导致的误删。

   fs::path user_input = "some/../path"; fs::path safe_path = fs::weakly_canonical(user_input); // 即使路径不存在也能处理 // 添加安全检查：确保要删除的目录在某个“安全区”内 fs::path safe_base = "/allowed/to/delete/here"; if (safe_path.string().find(safe_base.string()) != 0) { throw std::runtime_error("Deletion path is outside the safe zone!"); } // ... 然后才能考虑 remove_all

4. 实现“垃圾箱”功能：对于重要应用，不要直接删除，而是先移动到某个临时回收站目录，定期清理。这给了操作一个回滚的机会。

6. 符号链接与硬链接操作

链接是文件系统的高级特性，std::filesystem也提供了支持。

6.1 创建链接

• 创建符号链接（软链接）：fs::create_symlink(target, link)。target可以是相对或绝对路径，存储在链接文件中。

  // 创建指向文件的符号链接 fs::create_symlink("/original/file.txt", "link_to_file"); // 创建指向目录的符号链接 fs::create_directory_symlink("/original/dir", "link_to_dir");

  在Windows上，创建目录符号链接可能需要管理员权限，或者启用开发者模式。

• 创建硬链接：fs::create_hard_link(target, link)。target必须是一个已存在的文件（不能是目录），并且与链接必须在同一个文件系统内。硬链接是同一个文件的另一个名字，删除任何一个名字都不会影响文件数据，直到最后一个链接被删除。

  fs::create_hard_link("original.txt", "hardlink.txt");

6.2 读取链接

使用fs::read_symlink(link_path)来获取符号链接指向的目标路径。对于硬链接，没有直接的“读取”API，因为一个文件可能有多个硬链接，它们地位平等。

try { fs::path target = fs::read_symlink("my_symlink"); std::cout << "Symlink points to: " << target << '\n'; } catch (const fs::filesystem_error& e) { if (e.code() == std::errc::invalid_argument) { std::cout << "The path is not a symlink.\n"; } }

7. 错误处理：与异常和错误码共舞

std::filesystem的函数有两种错误处理方式：

1. 抛出异常：这是默认行为。函数失败时会抛出std::filesystem_error异常。这个异常继承自std::system_error，包含了详细的错误信息：操作类型、路径1、路径2（如果有）以及底层的std::error_code。
2. 使用std::error_code输出参数：每个可能抛出异常的函数都有一个重载版本，其最后一个参数是一个std::error_code&。如果提供这个参数，函数会将错误码填入其中，而不是抛出异常。

7.1 如何选择？

• 对于可恢复的、预期的错误，使用error_code。例如，检查文件是否存在，不存在不是错误，是正常情况。

  std::error_code ec; bool exists = fs::exists(some_path, ec); if (ec) { // 真正的错误发生了（如权限不足） std::cerr << "Error checking existence: " << ec.message() << '\n'; } else { // exists 变量反映了真实的存在状态 }

• 对于不可恢复的、非预期的错误，或者你希望错误能自动向上传播的场景，让异常抛出。例如，在程序初始化时必须成功创建一个配置目录，失败就应该让程序终止或回滚。

  try { fs::create_directories(essential_config_path); } catch (const fs::filesystem_error& e) { std::cerr << "Fatal: Could not create config directory: " << e.what() << '\n'; std::cerr << "Path1: " << e.path1() << '\n'; // 可能快速失败退出，或尝试恢复 std::exit(1); }

7.2 理解std::filesystem_error

这个异常非常有用。e.what()会返回一个描述性的字符串。e.code()返回std::error_code。e.path1()和e.path2()返回与此错误相关的路径（不是所有错误都有两个路径）。

try { fs::copy(src, dst); } catch (const fs::filesystem_error& e) { std::cerr << "Filesystem error: " << e.what() << '\n'; std::cerr << "Code: " << e.code() << " (" << e.code().message() << ")\n"; std::cerr << "Path1: " << e.path1() << '\n'; if (!e.path2().empty()) { std::cerr << "Path2: " << e.path2() << '\n'; } }

8. 实战：一个简单的项目文件清理工具

让我们把上面的知识组合起来，写一个实用的小工具：清理项目构建目录（如build、CMakeFiles、.o文件等）。

#include <filesystem> #include <iostream> #include <vector> #include <string> #include <set> namespace fs = std::filesystem; // 定义要删除的目录名和文件扩展名 const std::set<std::string> dirs_to_remove = {"build", "CMakeFiles", ".vs", "x64", "Debug", "Release"}; const std::set<std::string> files_to_remove = {".o", ".obj", ".so", ".a", ".lib", ".dll", ".exe", ".pdb", ".ilk", ".log", ".tlog", ".idb"}; bool should_remove_dir(const fs::path& dir_name) { return dirs_to_remove.find(dir_name.string()) != dirs_to_remove.end(); } bool should_remove_file(const fs::path& file_path) { return files_to_remove.find(file_path.extension().string()) != files_to_remove.end(); } void clean_project_directory(const fs::path& project_root, bool dry_run = true) { std::error_code ec; // 使用 recursive_directory_iterator 并跳过无权限目录 auto options = fs::directory_options::skip_permission_denied; for (auto it = fs::recursive_directory_iterator(project_root, options, ec); it != fs::recursive_directory_iterator(); ++it) { if (ec) { std::cerr << "Warning: Skipping due to error: " << ec.message() << " at " << it->path() << '\n'; ec.clear(); it.disable_recursion_pending(); // 跳过这个有问题的目录 continue; } try { const auto& entry = *it; if (entry.is_directory()) { if (should_remove_dir(entry.path().filename())) { std::cout << (dry_run ? "[DRY RUN] Would remove dir: " : "Removing dir: ") << entry.path() << '\n'; if (!dry_run) { // 注意：这里删除目录后，迭代器会失效。 // 一种方法是先收集路径，遍历完再删除。另一种是使用 postfix increment。 // 这里采用先收集再删除的策略更安全，为了示例简单，我们打印而不实际删除。 // fs::remove_all(entry.path()); } it.disable_recursion_pending(); // 标记，不要进入这个即将被删除的目录 } } else if (entry.is_regular_file()) { if (should_remove_file(entry.path())) { std::cout << (dry_run ? "[DRY RUN] Would remove file: " : "Removing file: ") << entry.path() << '\n'; if (!dry_run) { // fs::remove(entry.path()); } } } } catch (const fs::filesystem_error& e) { std::cerr << "Error processing " << it->path() << ": " << e.what() << '\n'; // 通常选择跳过这个有问题的条目 it.disable_recursion_pending(); } } } int main(int argc, char* argv[]) { fs::path root = (argc > 1) ? fs::path(argv[1]) : fs::current_path(); root = fs::weakly_canonical(root); // 规范化路径 std::cout << "Cleaning project under: " << root << "\n\n"; std::cout << "--- DRY RUN MODE (no actual deletion) ---\n"; clean_project_directory(root, true); // 干跑模式 std::cout << "\nProceed with actual deletion? (yes/no): "; std::string answer; std::cin >> answer; if (answer == "yes" || answer == "y") { std::cout << "\n--- ACTUAL CLEANUP ---\n"; clean_project_directory(root, false); } else { std::cout << "Cleanup cancelled.\n"; } return 0; }

这个工具的关键点：

1. 安全第一：默认使用“干跑”模式，先列出要删除的内容，让用户确认。
2. 路径规范化：使用weakly_canonical处理输入路径，避免.和..带来的混淆。
3. 错误处理：遍历时使用error_code和异常捕获相结合，确保遇到个别问题（如权限不足）时能跳过并继续，而不是整个程序崩溃。
4. 迭代器控制：当决定要删除一个目录时，调用disable_recursion_pending()防止迭代器进入其中，这是安全的，因为我们马上就要删除它了（在实际删除版本中）。
5. 实际删除的复杂性：在递归遍历过程中直接删除条目是危险的，因为删除目录会使指向它的迭代器失效。更健壮的做法是：在干跑模式或第一次遍历时，将要删除的文件路径收集到一个std::vector<fs::path>中，将要删除的空目录路径收集到另一个容器中。遍历结束后，先删除所有文件，然后按目录深度从深到浅的顺序删除空目录。对于非空目录（如build），直接对整个目录调用remove_all。这避免了迭代器失效问题。

9. 跨平台注意事项与编译器支持

虽然std::filesystem是标准库，但不同平台和编译器仍有细微差别。

• C++17 支持：你需要确保你的编译器支持C++17或更高版本，并启用了文件系统库。

  • GCC/G++: 版本 >= 8.1，编译时添加-std=c++17 -lstdc++fs(GCC 8/9 需要链接库，GCC 10+ 通常不需要)。
  • Clang: 版本 >= 7.0，编译时添加-std=c++17 -lc++fs(使用libc++时) 或-lstdc++fs(使用libstdc++时)。
  • MSVC (Visual Studio): VS 2017 15.7 及以上版本，项目属性中设置C++ Language Standard为ISO C++17 Standard或更高。通常不需要额外链接库。

• 路径分隔符：尽管path类处理了/和\，但在输出或与字符串交互时要注意。path.string()返回原生格式（Windows是\，Linux是/）。如果需要可移植的字符串表示，可以使用path.generic_string()，它总是使用/作为分隔符。

• 文件权限：Windows和POSIX系统的权限模型差异很大。fs::perms在Windows上可能只有少数几位有意义（如只读属性）。设置权限fs::permissions(p, perms)在跨平台时行为可能不一致。

• 符号链接：Windows上创建符号链接可能需要提升的权限（以管理员身份运行）或启用“开发者模式”。对于普通用户，create_symlink可能失败。

• 文件大小类型：fs::file_size返回std::uintmax_t，通常是64位无符号整数，足以处理大文件。

• Unicode 支持：fs::path在Windows上内部使用wchar_t（UTF-16），在POSIX上使用char（UTF-8）。用UTF-8字符串构造路径在跨平台时通常是最安全的方式。避免使用本地编码（如GBK）。

我个人在实际项目中的体会是，std::filesystem极大地提升了代码的清晰度和可维护性。虽然初期需要适应其错误处理方式和一些跨平台的坑，但一旦掌握，它就成了处理文件I/O的首选工具。对于更复杂的场景（如监控文件变化、内存映射文件等），你可能还需要依赖平台特定API或第三方库，但对于90%的日常文件操作任务，std::filesystem已经完全够用且是最佳选择。最后一个小技巧：在编写涉及大量文件操作的代码时，善用std::filesystem::path的/运算符来构建路径，这比字符串拼接安全、清晰得多。