宏定义和注释乱码本质是文件编码与编译器/编辑器解析编码不匹配，需统一为utf-8（无bom）保存，并显式指定编译器输入/执行编码，或改用unicode转义；vscode需禁用自动猜测、手动重载编码，批量项目可用iconv转换。
宏定义乱码：本质是文件编码与预处理器不匹配
宏定义本身不会“产生”乱码，但当你在 #define 中写中文字符串（比如 #define MSG "你好"），而文件保存为 GBK、编译器却按 UTF-8 解析源码时，预处理器读到的字节流就错了。GCC/Clang 默认假设源文件是 UTF-8，Windows 上的 MSVC 有时默认用本地代码页（如 CP936/GBK）。结果就是字符串字面量解码失败，编译后输出或调试时看到“浣犲ソ”“锟斤拷”这类字符。
- 确认当前文件真实编码：右下角状态栏点编码名 → 选
Reopen with Encoding→ 试GBK和UTF-8，看宏值是否恢复正常 - 统一用 UTF-8 保存：若宏里必须含中文，务必用
UTF-8（无 BOM）保存文件；VSCode 状态栏点编码 →Save with Encoding→ 选UTF-8 - 编译器显式指定编码：GCC 加
-finput-charset=UTF-8 -fexec-charset=GBK（后者控制运行时字符串编码）；MSVC 用/source-charset:utf-8 /execution-charset:gbk - 避免宏中直接写中文：改用 Unicode 转义，如
#define MSG u8"\u4f60\u597d"，这样无论源文件编码如何，都能稳定解析
中文注释乱码：不是显示问题，是解码链路断了
注释乱码和宏定义乱码同源，但表现更隐蔽——因为注释不参与编译，你只能在编辑器里看到它乱。根本原因还是 VSCode 按错误编码打开了文件。特别注意：VSCode 不会因为注释里有中文就自动切编码，它的“自动检测”对纯注释内容基本失效。
- 别信状态栏显示的编码名：它只是上次保存时记录的，不一定反映文件真实编码。右键文件标签 →
Reopen with Encoding才是真实重载 - 禁用自动猜测：在设置里把
files.autoGuessEncoding设为false，避免 VSCode 在 GBK 文件里强行套 UTF-8 解码，越猜越乱 - 检查
files.encoding全局配置：设成utf8是安全起点，但不能解决已存为 GBK 的老文件——这类文件必须手动Reopen with Encoding - 终端里跑程序也乱？那可能是
chcp 65001没生效，或程序输出用了wprintf却没调_setmode(_fileno(stdout), _O_U16TEXT)
批量处理老项目：别一个个点，用命令行转编码
接手一个满是 GBK .c/.h 文件的老项目，靠右下角点几十次不现实。核心思路是：先批量转文件内容为 UTF-8，再让 VSCode 统一按 UTF-8 处理。
- Windows 下用
iconv（需安装 Git for Windows 或 MinGW）：iconv -f GBK -t UTF-8 input.c -o output.c - Linux/macOS 直接用系统
iconv，加-c忽略非法字节：find . -name "*.h" -exec iconv -f GBK -t UTF-8 -c {} -o {}.utf8 \; - VSCode 插件可选
Encode Decode：装好后右键文件 →Encode/Decode: Convert to UTF-8，适合小范围补救 - 转完立刻验证：打开新文件，状态栏应显示
UTF-8，且注释、宏字符串、甚至// TODO: 修复XXX都清晰可读
容易被忽略的硬伤：字体和 BOM
即使编码全对，中文仍可能显示为方块或错位，这时候问题不在解码，而在渲染层。VSCode 默认字体在某些系统上压根不带中文字形，或者 UTF-8 BOM 导致工具链误判。
- 强制指定中文字体：设置
editor.fontFamily为"Fira Code", "Microsoft YaHei", "SimSun", "monospace"，逗号分隔，fallback 到系统宋体 - BOM 是双刃剑：UTF-8 with BOM 能帮 VSCode 识别编码，但 Python 解释器、Makefile、Shell 脚本会把它当垃圾字符读，导致语法错误。保存时选
UTF-8而非UTF-8 with BOM - Git 提交前检查：用
git add -v看是否有encoding: utf-8-bom类提示，有就说明文件带 BOM，需用dos2unix或 VSCode 右键“Remove BOM”清理
