std::filesystem 在 C++17 中必须显式链接 stdc++fs
很多编译器（尤其是 GCC 8–11）不会自动链接 std::filesystem 所需的底层库，即使你写了 #include 并用了 std::filesystem::exists() 这类函数，链接阶段仍会报错：undefined reference to `std::filesystem::status'。
解决方法是编译时加链接选项：
g++ -std=c++17 main.cpp -lstdc++fs
Clang 同样需要：-lstdc++fs（Linux/macOS）或 -lc++fs（部分新版 Clang + libc++ 环境）。MSVC 2017 及以后通常无需额外链接，但需确保项目设置中启用了 C++17 标准。
- Windows 下用 MinGW-w64 时，
-lstdc++fs依然必要 - CMake 中应写：
target_link_libraries(my_target stdc++fs)，而非仅靠find_package(Threads)等惯用写法 - 不链接会导致运行时崩溃或链接失败，不是编译期错误，容易误判为代码问题
路径拼接别用 operator+/ 字符串拼接，用 path / path
std::filesystem::path 重载了 / 操作符用于安全拼接，它会自动处理分隔符（/ 或 \）、冗余斜杠、相对路径归一化。直接字符串拼接或用 + 极易出错。
立即学习“C++免费学习笔记（深入）”；
错误写法：
std::filesystem::path p = "/home" + "/" + "user"; // 编译失败：不能 string + path
更隐蔽的错误：
std::string base = "C:\\temp"; std::string file = "log.txt"; auto p = std::filesystem::path(base + "\\" + file); // 手动拼接反斜杠，跨平台失效
正确写法：
auto p = std::filesystem::path("/home") / "user" / ".config" / "app.conf";
// 自动适配平台分隔符，且忽略多余斜杠："/home//user/./.config/app.conf" → "/home/user/.config/app.conf"
-
path / const char*和path / path都可用，优先用/而非+= -
path.append()是底层操作，一般不需要；operator/=等价于append()，语义不如/清晰 - 拼接含用户输入的路径时，
/会自动过滤空段（如""或"."），而字符串拼接不会
遍历目录时注意 directory_iterator 不递归，用 recursive_directory_iterator
std::filesystem::directory_iterator 只遍历指定目录的**直接子项**，不会进入子目录。想实现类似 find . -name "*.txt" 的效果，必须用 recursive_directory_iterator。
常见误用：
for (const auto& entry : std::filesystem::directory_iterator("/data")) {
if (entry.is_regular_file() && entry.path().extension() == ".log") {
process(entry.path());
}
} // ❌ 只扫 /data 下的文件，不进 /data/logs/、/data/cache/ 等子目录
正确方式：
for (const auto& entry : std::filesystem::recursive_directory_iterator("/data")) {
if (entry.is_regular_file() && entry.path().extension() == ".log") {
process(entry.path());
}
}
-
recursive_directory_iterator默认跳过符号链接指向的目标（即不跟随 symlink），如需跟随，构造时传std::filesystem::directory_options::follow_directory_symlink - 遍历时若目录被外部删除或权限变更，迭代器可能抛
std::filesystem::filesystem_error，建议用std::error_code版本构造避免异常中断 - 性能上，递归迭代比单层略慢，但对大多数应用可忽略；如只需一层，坚持用
directory_iterator更明确
检查文件存在性和类型要用 status() + is_*()，别只靠 exists()
std::filesystem::exists(p) 返回 true 仅表示路径“存在且可访问”，但它可能是损坏的符号链接、无权限读取的文件、甚至挂起的 NFS 路径。真正判断“这是一个普通文件”或“这是个可执行目录”，应调用 status(p) 或 symlink_status(p)，再用 is_regular_file() 等谓词。
典型陷阱：
if (std::filesystem::exists(p)) {
std::ifstream f(p); // ❌ 即使 exists() 为 true，f 构造仍可能失败（权限/链接断裂/设备忙）
}
更稳健的做法：
std::error_code ec;
auto s = std::filesystem::status(p, ec);
if (!ec && std::filesystem::is_regular_file(s)) {
std::ifstream f(p);
// ✅ 此时打开成功率高得多
}
-
status()会尝试解析符号链接目标，symlink_status()只查链接自身（适合判断是否为 symlink） - 所有
is_*函数（如is_directory()）都要求先有合法file_status对象，不能直接对path调用 - 在多线程或 NFS 环境下，
exists()和后续打开之间存在竞态窗口，status()+error_code版本能减少此类问题
std::filesystem 的每个函数背后都有平台差异、符号链接策略、权限模型和错误传播路径——最常被忽略的是链接步骤和 status() 的必要性。
