这不是语法错误，而是源文件混入了编译器不认识的非ASCII字符，如中文标点、全角符号、UTF-8 BOM或零宽字符，导致gcc报“stray”错误；删掉或替换这些字符即可通过编译。
直接说结论：这不是语法错误，是源文件混入了编译器不认识的非ASCII字符，gcc 把它们当成“流浪字符”（stray）报错。删掉或替换掉这些字符就能过编译，不用改逻辑。
报错行里有中文标点或全角符号
这是最常见原因。比如你从网页、微信、Word 里复制代码，" 变成 “”，, 变成 ，，; 变成 ；，. 变成 。——这些在编辑器里看着像，但底层是 Unicode 全角字符，gcc 完全不认。
- 重点检查报错行及前后几行，尤其引号、括号、分号、逗号、句号
- 用编辑器「显示不可见字符」功能（如 VS Code 的
Ctrl+Shift+P→ “Toggle Render Whitespace”）能快速暴露全角空格和标点 - 别依赖“查找替换”，有些全角字符在普通替换里不匹配；最稳妥的是把整行删掉，切换英文输入法，重新手打一遍
文件开头带 UTF-8 BOM
Windows 记事本、某些版本的 Notepad++ 默认保存为 UTF-8 with BOM，开头三个字节 737（即 0xEF 0xBB 0xBF）对 gcc 来说是非法内容，报错就集中在第 1 行。
- 用
file -i filename.c查编码：如果输出含charset=utf-8; with BOM，基本就是它 - VS Code：右下角点击编码名 → “Save with Encoding” → 选
UTF-8（注意不是UTF-8 with BOM） - 命令行快速去 BOM：
sed '1s/^\xEF\xBB\xBF//' source.c > clean.c，再用clean.c编译
粘贴引入零宽字符或控制符
从 PDF、在线文档、甚至某些笔记 App（如有道云笔记）复制代码时，可能带入 \302\240（NBSP）、\u200b（零宽空格）等肉眼不可见字符，gcc 解析到就报 stray '\302' 或类似。
- 这类字符不会被普通“显示空格”功能标出，需用支持十六进制视图的编辑器（如 VS Code 插件 Hex Editor）确认
- 更实用的办法：把报错行复制进在线工具如 View Chars，看每个字符的 ASCII/Unicode 码
- 临时应急：整行内容复制到纯文本编辑器（如 macOS 的 TextEdit 切换到“纯文本”模式，Windows 记事本），再复制回源文件
BOM 和全角符号问题容易反复出现，尤其在跨平台协作或从非开发环境取代码时。真正省事的做法不是每次手动修，而是把编辑器默认编码设为 UTF-8 without BOM，并养成写代码时全程用英文输入法的习惯——哪怕只是敲个空格，也比事后花十分钟定位 \240 强。
