std::filesystem::path 构造含反斜杠的 Windows 路径时崩溃，因 C++ 字符串字面量中 是转义符，导致路径解析错误；应使用原始字符串 R"(C: emp ile.txt)" 或正斜杠 "C:/temp/file.txt"，运行时路径需确保 JSON 等解析已正确处理双反斜杠，调试时用十六进制 dump 验证真实字节。
为什么 std::filesystem::path 直接构造会崩在带反斜杠的 Windows 路径上
因为 C++ 字符串字面量里 是转义符，不是路径分隔符。你写 "C:Users
amedoc"，编译器实际看到的是 C:sers ameoc——U、
、d 全被当成了转义序列，轻则路径错乱，重则编译失败或运行时 std::filesystem::path 构造失败（抛 std::filesystem::filesystem_error）。
常见错误现象：std::filesystem::path p("C: emplog.txt"); 编译不报错但运行时报 “No such file or directory”，实际是因为路径根本没解析对。
- 用原始字符串字面量：改写成
R"(C: emplog.txt)"，不再被解释，原样保留 - Windows 下推荐统一用正斜杠：
"C:/temp/log.txt"，std::filesystem::path内部自动兼容，且避免所有转义问题 - 如果必须拼接路径（比如变量 + 固定后缀），别用
+拼 raw string，而要用path的/重载：std::filesystem::path base = R"(C:data)"; auto full = base / "config.json";
遇到含 u、x、 的 JSON 或配置文件路径怎么安全解析
这类字符串不是编译期字面量，而是运行时读入的（比如从 JSON 解析出的 "path": "C:\Users\john\file.txt"），此时反斜杠已按 JSON 规范被解析为单个 ，但 C++ 字符串里它仍是普通字符——问题在于你得确保它没被二次转义。
典型陷阱：用 std::regex 或手写替换把 "\\" 替成 "\"，结果越替越错；或者用 std::string::replace 无脑删 "\"，把合法路径分隔符也干掉了。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 优先交给
std::filesystem::path自动归一化：它能识别连续\并合并，也能处理混合斜杠（C:/a/c合法） - 若需预处理（如清理非法控制字符），只针对明确非法的 Unicode 转义（如
u0000）做校验，别碰路径结构本身 - 读取 JSON 时用成熟库（如 nlohmann/json），它默认将
"C:\\tmp"正确解码为C: mp字符串，你拿到的就是干净的std::string，直接传给std::filesystem::path即可
std::filesystem::path 在跨平台代码里对原始字符串的兼容性差异
原始字符串 R"(ac)" 在 Linux/macOS 上不会出错，但语义和 Windows 完全不同： 是退格符，c 是非法转义——即使放在 raw string 里， 和 c 仍会被编译器当作转义序列处理，raw string 只对 后跟非字母数字字符才“免疫”。
也就是说，R"(ac)" 实际等价于 "ac"（含一个退格符），不是你想要的字面量 ac。
- 绝对不要在 raw string 里混用转义含义字符：避免
R"(C: emp)"这种写法， - 跨平台路径字面量，统一用正斜杠 + 原始字符串：
R"(a/b/c)"或R"(C:/data/config.json)"，安全且无歧义 - Linux 下路径含空格或括号（如
/home/user (test)/file.txt）时，std::filesystem::path原生支持，无需额外引号或转义
调试时怎么一眼看出路径字符串到底长啥样
打印 std::string 看不到真实内容——
显示成换行， 截断输出， 变成空白，你根本不知道字符串内部是不是藏了不可见字符。
最容易被忽略的点：你以为读进来的路径是干净的，其实 JSON 解析器、INI 解析器或手动 getline 都可能悄悄带入 BOM、尾随空格、CR（
）甚至零宽空格。
- 用十六进制 dump 查看真实字节：
for (unsigned char c : path_str) printf("%02x ", c);，一眼定位0d（CR）、00（NUL）、ef bb bf（UTF-8 BOM） - 检查长度是否异常：
path_str.size()比预期多 1？很可能是行末 - 构造
std::filesystem::path后立刻调用.string()或.generic_string()打印，比直接打原始std::string更可靠——它会做标准化，暴露归一化后的样子
