字符串字面量中写\表示一个反斜杠，因是转义符；raw字符串R"(...)"可避免转义，但定界符必须严格匹配且不可含括号与空白。
字符串字面量里写 \ 是为了表示一个反斜杠字符
很多人看到 "C:\Users\name" 一头雾水：为什么不是 "C:Users
ame"？因为 在 C++ 字符串字面量中是转义起始符，单独出现会尝试组合后续字符构成特殊含义（比如
、 ），而 U、
之外的组合（如 U 或孤立的 ）直接导致编译错误。
所以想表达一个真实的反斜杠，必须用两个：\。编译器看到它，就“消掉一层”，最终字符串里只剩一个 。
-
"a\b"→ 实际存储为 3 个字符：a、、b -
"\\"→ 存储为两个反斜杠（常见于 Windows 路径或正则表达式字面量） - 误写成
" "是合法的（换行符），但"U"或"z"会报错：unknown escape sequence
raw 字符串字面量可以绕过所有转义，但语法有硬性要求
如果你要写一堆路径、正则、SQL 或 JSON 片段，反复敲 \\ 很容易漏数、出错。这时候该上 raw 字符串：R"(...)"。
它的核心规则是：引号内的所有内容原样保留，不解析任何转义——包括 、"、
都只是普通字符。但代价是：定界符不能出现在内容里，否则提前截断。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 正确：
R"(C:Users ame ile.txt)"→ 字符串就是带反斜杠的原文 - 错误：
R"(say "hello")"→ 双引号冲突，编译失败 - 解法：用自定义分隔符，如
R"delim(say "hello")delim"，前后delim必须完全一致且不含括号和空白 - 注意：
R"(...)"中不能换行（除非用R"(... ...)"显式写R"delim(...)"支持跨行
std::string 构造时不会二次转义，别把运行时和编译期搞混
有人试过这样拼接路径：std::string path = "C:\" + username + "\file.txt";，结果发现输出乱码或崩溃。问题不在 std::string，而在第一部分 "C:\" —— 它在编译期就被处理成 C:（一个反斜杠），后面再拼接，和你预期的“两个反斜杠开头”已经不是一回事了。
关键点：转义只发生在字符串字面量被编译器读取时，一旦变成 std::string 对象，它就只是内存里一串字节，不会再“解释”里面有没有 。
- 错误示范：
"C: emp ew"→ 实际是C:emp w（ - 安全写法：要么全用
\，要么整个用 raw 字符串：R"(C: emp ew)" - 运行时拼接（比如从用户输入、配置文件读取路径）不需要考虑转义——那些字符串已经是“解码后”的了
Windows API 和正则库对反斜杠的容忍度不同，别假设通用
Win32 函数（如 CreateFileA）接受正斜杠 / 作为路径分隔符，也接受双反斜杠 \，但单个 在字符串字面量里根本活不到传参那一刻——它早被编译器当转义吃掉了。
而正则引擎（如 std::regex）更麻烦：它自己还要再解析一遍反斜杠。所以一个字面上的 d 在 C++ 字符串里得写成 "\d"（编译期去一层，正则引擎再吃一层），raw 字符串反而更清晰：R"(d)"。
-
std::regex re("\d+");→ 正确：编译后是d+，正则引擎识别为“数字重复” -
std::regex re("d+");→ 错误：d是非法转义，编译不过 -
std::regex re(R"(d+)");→ 等价且更易读，推荐用于复杂模式 - 注意：某些旧版 MinGW 或嵌入式 STL 实现对 raw string 的 Unicode 支持弱，遇到
u序列需额外验证
最常被忽略的是：raw 字符串的定界符不是可选的装饰，而是语法必需部分；少打一个括号、多打一个空格，编译器就拒绝合作。写完记得快速扫一眼首尾是否严格匹配。
