字符串字面量中反斜杠会触发编译器自动转义，导致路径等场景出错；应使用原始字符串r"(...)"绕过，windows下中文需u8前缀确保utf-8编码，std::string不兼容l""宽字符，原始字符串不取消语法解析仅取消转义。
字符串字面量里加反斜杠就报错？先看编译器是否在帮你“自动转义”
不是所有 "\n" 都真代表换行——C++ 编译器会在字符串字面量中主动处理转义序列，比如把 "\t" 变成制表符、"\"" 变成双引号本身。一旦你本意是写一个真实反斜杠（比如 Windows 路径 "C:\temp\log.txt"），它就会被拆解成非法组合：\t（制表符）和 \l（未定义转义），轻则警告，重则编译失败。
常见错误现象：warning: unknown escape sequence '\l' 或 error: missing terminating " character（因为 " 被 \" 吃掉了）。
- 用原始字符串字面量绕过转义：写成
R"(C:\temp\log.txt)"，里面的每个字符都按字面意思保留 - 原始字符串支持自定义分界符，避免内部出现
)"冲突：比如R"delim(C:\path"with"quote)delim" - 注意：原始字符串里不能换行（除非显式写
\n），也不能包含未配对的"或)——但加了分界符就能解决
UTF-8 字符串为什么在 Windows 控制台乱码？别漏掉 u8 前缀
写 "你好" 在 Linux/macOS 通常没问题，但在 MSVC 或 MinGW 下，源文件存为 UTF-8 时，编译器默认把它当 Latin-1 解释，结果生成的字符串字节序列是错的——控制台收到的是乱码字节，不是真正的 UTF-8。
使用场景：跨平台项目、中文路径、JSON 中文键名、日志输出含中文。
- 显式加上
u8前缀：u8"你好"，强制编译器按 UTF-8 解码源码并生成 UTF-8 字节序列 -
u8只影响字符串字面量的编码解释，不改变类型：仍是const char*，不是char8_t*（C++20 才有后者） - MSVC 默认不启用 UTF-8 源文件识别，即使加了
u8，也建议配合编译选项/utf-8（或保存为 UTF-8 with BOM） - Clang/GCC 更宽松，但加
u8是最稳妥的跨编译器写法
std::string 能直接存 L"宽字符"吗？不能，类型不兼容
L"hello" 是 const wchar_t*，而 std::string 底层是 char 序列。直接赋值会触发隐式转换失败，编译器报错：cannot convert 'const wchar_t*' to 'const char*'。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
性能影响：宽字符到多字节的转换（如 WideCharToMultiByte）涉及查表、内存分配、编码检测，不是零成本操作。
- Windows 上若需与 Win32 API 交互（如
CreateFileW），优先用std::wstring存L"..." - 跨平台项目慎用
L""：Linux/macOS 的wchar_t是 32 位，Windows 是 16 位（UTF-16），语义不一致 - 如果必须转成
std::string，用标准库不提供直接转换——得调系统 API 或第三方库（如 ICU、iconv），别手写循环
raw string literal 里能嵌套注释或换行吗？可以，但别误以为它能“取消语法”
原始字符串只取消转义，不取消 C++ 语法解析。比如 R"(int x = 1; /* comment */)" 是合法字符串内容，但如果你写成 R"(if (x > 0) {)"，后面又没闭合大括号，编译器仍会报错：不是字符串问题，是代码结构不完整。
容易踩的坑：
- 原始字符串不能跨文件；预处理器指令（如
#include）不能出现在其中 - 结尾的
)"必须顶格、无空格、无注释——哪怕只有一个空格也会让编译器找不到终止符 - VS IntelliSense 有时高亮异常，但不影响编译；GCC/Clang 对原始字符串的诊断更准确
最常被忽略的一点：原始字符串的编码仍受源文件编码和前缀（u8、L、u、U）控制——R"(...)" 本身不指定编码，u8R"(...)" 才是 UTF-8 原始字符串。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
