GCC报stray '\357'错误源于UTF-8 BOM（\357\273\277）或全角字符等非法字节，因其按ASCII/Latin-1解析多字节UTF-8序列而触发词法分析失败，解决需转存为UTF-8 without BOM、清除隐藏字符或切换英文输入法重输。
gcc 报 stray '\357' 是因为读到了 UTF-8 BOM 或非法字节
GCC 默认按纯 ASCII 或 Latin-1 解析源文件，遇到 UTF-8 编码的多字节序列（比如 BOM \357\273\277）时，会把每个字节单独当成“流浪字符”（stray character）处理。这不是语法错，是编码层解析失败。常见于用记事本保存为 UTF-8（带 BOM）的 .cpp 文件，或从网页复制后残留的隐藏字节。
解决方法很简单：
– 用 VS Code、Notepad++ 等编辑器将文件另存为 UTF-8 without BOM 或 ANSI（即系统本地编码，如 Windows-1252）；
– 在终端用 file -i main.cpp 查看实际编码；
– 若确认是 BOM，可用 sed -i '1s/^\xEF\xBB\xBF//' main.cpp 去掉开头三字节。
error C3872: '0x3000' 指的是全角空格，不是普通空格
Visual Studio 遇到 0x3000（Unicode 全角空格）会直接报错，因为它不允许非 ASCII 空白出现在标识符中。这个字符常来自中文输入法下的空格键，视觉上和 0x20（半角空格）几乎一样，但编译器词法分析器完全不认。
排查建议：
– 在 VS 中打开「显示空白字符」（Ctrl+R, Ctrl+W），全角空格会显示为两个宽格子；
– 查找替换时用正则：[[:space:]] 不匹配它，必须显式写 \u3000；
– 批量替换推荐：查找 \u3000，替换为 （一个半角空格）；
– 更稳妥的做法是删掉整行，切英文输入法重打。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
引号、括号、分号混用全角符号，GCC 不报行号但直接失败
从微信、知乎、Word 复制代码时，" 可能变成 “”，( 变成 （，; 变成 ；。GCC 无法识别这些 Unicode 字符，会报类似 stray '\221' 的错误——数字是该字符 UTF-8 编码的第一个字节。
关键点：
– 错误位置往往不在报错行本身，而在上一行末尾或下一行开头；
– 不要依赖普通「查找替换」，全角引号在默认搜索里不被当作引号匹配；
– VS Code 中开启「Render Whitespace」+「Show Invisibles」，能同时暴露全角标点和零宽字符；
– 最省事方案：把疑似段落全选 → 剪切 → 切换英文输入法 → 粘贴 → 手动补回必要符号。
为什么 IDE 不总提醒？因为这是预处理阶段就卡住的底层问题
这类错误发生在 GCC 的词法分析（lexer）阶段，早于语法检查。编译器还没开始解析 if 或 for，就已经被非法字节拦下了。所以 IDE 的语法高亮、智能提示、实时错误标记往往失效——它连 token 都切不出来。
这意味着：
– 不能靠「编译失败再改」来调试，得先确保文件干净；
– CI 流水线里如果用 Linux + GCC，而开发者在 Windows 上用带 BOM 的 UTF-8 提交，就会出现「本地能编，CI 过不了」；
– 跨平台协作时，建议在项目根目录加 .editorconfig，强制 charset = utf-8 且 utf8_bom = false。
