std::filesystem::path 应用 operator/ 拼接而非字符串拼接，以确保跨平台分隔符归一化；canonical() 易抛异常，优先用 absolute()；递归遍历须用 recursive_directory_iterator；编译需启用 c++17 并链接 stdc++fs。
std::filesystem::path 构造时别直接拼字符串
用 operator/ 拼接路径，不是 + 或 std::string::append。Windows 用反斜杠、Linux/macOS 用正斜杠，std::filesystem::path 内部会自动归一化分隔符，但手动拼字符串会绕过这个逻辑，导致跨平台行为不一致。
常见错误现象：在 Windows 上构造 "C:\foo" + "\" + "bar" 看似可行，但在 macOS 上生成 "C:\foo\bar"，exists() 返回 false——因为路径根本不存在，且不会报错，只静默失败。
- 正确写法：
std::filesystem::path p = "foo" / "bar" / "config.json" - 避免写法：
std::filesystem::path p("foo" + "/" + "bar")（字符串拼接丢失路径语义） - 从字符串构造时，优先用
std::string_view或 C 字符串字面量，避免隐式转换干扰
std::filesystem::canonical() 在符号链接和权限不足时容易抛异常
std::filesystem::canonical() 试图返回绝对、规范、可访问的路径，但它不是“尽力而为”——遇到符号链接循环、目标不可达、无读权限等情况，直接抛 std::filesystem::filesystem_error。很多开发者把它当“安全转绝对路径”用，结果上线后在某些目录突然崩溃。
使用场景：你真正需要的是“能打开的路径”，而不是“数学上最简的路径”。多数时候 std::filesystem::absolute() 更稳妥，它只做基础补全，不解析符号链接也不检查目标是否存在。
立即学习“C++免费学习笔记（深入）”；
- 用
absolute()替代canonical()：除非你明确需要展开 symlink 并验证可达性 - 必须用
canonical()时，务必try/catch捕获std::filesystem::filesystem_error - 注意：即使
canonical()成功，也不能保证后续open()一定成功——权限、竞态、NFS 挂载状态都可能变化
遍历目录时 std::filesystem::directory_iterator 不递归，std::filesystem::recursive_directory_iterator 才递归
名字很直白，但实际用错率很高。有人以为 directory_iterator 默认递归，或者以为加个 while 循环就能进子目录——它只遍历一级，子目录只是普通 directory_entry，不会自动展开。
性能影响明显：递归遍历时，recursive_directory_iterator 内部做了栈管理与路径缓存，比手写递归调用 directory_iterator 更轻量；而误用非递归迭代器再自己 if (is_directory()) 后重开迭代器，会反复 stat、重复打开目录句柄，尤其在大量小目录时 I/O 开销翻倍。
- 要递归遍历：用
std::filesystem::recursive_directory_iterator - 要跳过某些子树（比如
.git）：调用其disable_recursion_pending()方法，在进入该目录前设 flag - 注意：两个迭代器都不保证顺序，如需排序，先收集到
std::vector再std::sort
编译时忘记链接 stdc++fs 或启用 C++17 支持
很多构建系统默认不开 C++17，或没显式链接 stdc++fs 库（GCC），导致链接期报一堆 undefined reference，比如：undefined reference to 'std::filesystem::u8path(std::string const&)。
这不是代码问题，是构建配置漏项。Clang 和 GCC 都要求显式链接，MSVC 则内置支持但依赖语言标准版本。
- 确认编译参数含
-std=c++17（或更高） - GCC/Clang 必须加
-lstdc++fs（放在链接命令末尾） - CMake 中应写：
target_link_libraries(my_target PRIVATE stdc++fs)，并确保set(CMAKE_CXX_STANDARD 17) - 注意：macOS 的 libc++ 目前不完全支持
std::filesystem（截至 clang 16），CI 上跑 macOS 时建议 fallback 到boost::filesystem或条件编译
路径处理真正的复杂点不在 API 调用，而在“路径是否代表真实存在、能否被当前进程以所需方式访问”——std::filesystem 提供了工具，但不代替你做权限判断、竞态处理和错误恢复。尤其是 exists() 和 is_regular_file() 这类查询，永远只能反映调用瞬间的状态。
