std::filesystem::path构造时windows下反斜杠不报错但行为异常，因c++字符串字面量将“ ”“”解析为转义字符，导致路径乱码；应使用原始字符串r"(c: ooar)"或正斜杠"/tmp/cache"。
std::filesystem::path构造时为何在Windows上反斜杠不报错但行为异常
因为std::filesystem::path在构造时会按当前平台规则解析分隔符，Windows下"C: ooar"里的 和被当作转义字符处理，实际传入的是C:♀o♂ar这类乱码路径。这不是bug，是C++字符串字面量本身的语义问题。
实操建议：
- 一律使用原始字符串字面量：
R"(C: ooar)"或R"(/home/user/data)" - 用正斜杠硬编码也完全可行（
std::filesystem内部会自动转换）："/tmp/cache"在Windows下会被正确映射为C: mpcache（取决于当前驱动器） - 避免拼接字符串：不要写
std::string("C:\") + name再转path，直接用path的/重载操作符
跨平台路径拼接该用/还是operator/=
/ 是推荐的拼接方式，它返回新path对象；/= 是就地修改。两者在语义和行为上完全一致，都遵守平台感知规则：Linux下生成/a/b/c，Windows下生成ac（或C:c，取决于左操作数是否为绝对路径）。
容易踩的坑：
-
path p = "a"; p /= "b" /= "c";没问题，但p /= "/b/c"会导致p变成/b/c（前面的a被丢弃），因为/=遇到绝对路径组件会重置 - 不要混用
std::string::operator+和path：p += "/sub"是错误的——+=对path未定义，编译失败 - 若需动态拼接多个变量，用
std::filesystem::path{a} / b / c比反复/=更清晰、不易出错
canonical()和absolute()在不同系统上为何返回不同结果
std::filesystem::absolute(p)只是补全为绝对路径（基于当前工作目录），不做存在性检查；而canonical(p)要求路径必须存在，且会解析..、.、符号链接，最终返回“最简绝对路径”。这两者在跨平台部署时表现差异明显：
- Linux/macOS下
canonical()能正确展开~或环境变量（如果路径里写了$HOME，需先std::filesystem::expand_path，但标准库不提供，得自己做） - Windows下
canonical()对NTFS符号链接支持良好，但对Junction Points行为不稳定，某些版本会静默失败 - 若路径不存在，
canonical()抛std::filesystem::filesystem_error，错误码通常是std::errc::no_such_file_or_directory，务必捕获
判断路径是否存在且是目录时为什么exists(p) && is_directory(p)仍可能出错
竞态条件：两次调用之间路径可能被删除或改类型。更安全的做法是直接调用is_directory(p)，它在内部会先检查存在性；但如果需要区分“不存在”和“存在但不是目录”，就得分开判断并容忍竞态。
实操要点：
-
is_directory(p)返回false不意味路径不存在——它也可能是个文件、socket或权限不足导致无法访问 - Windows下注意长路径限制：
\?C: erylongpath格式才能绕过260字符限制，但std::filesystem::path默认不加前缀，需手动构造原始路径字符串再传入 - 某些CI环境（如GitHub Actions Windows runner）默认关闭符号链接支持，
is_symlink()恒返回false，需检查std::filesystem::is_symlink_supported()
path对象的行为符合各系统的底层约定。最易被忽略的是：所有I/O操作（create_directories、copy等）都依赖path的内部表示，而非你打印出来的字符串形式。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
