根本原因是g++生成的字符串字节序列与Windows终端（CP936/GBK）解码方式不匹配；最稳妥解法是在tasks.json中同时添加-finput-charset=utf-8和-fexec-charset=GBK，确保源码UTF-8解析、输出GBK编码，并配合UTF-8无BOM文件及纯英文路径。
VSCode 运行 C++ 程序时终端输出中文乱码，根本原因不是代码写错了，而是 g++ 编译出的字符串字节序列和 Windows 终端（cmd 或 PowerShell）解码方式不匹配。最直接有效的解法是让编译器“说人话”——明确告诉它：源码是 UTF-8，但生成的可执行文件里中文字符串得按 GBK 存。
在 tasks.json 中加对编译参数：-finput-charset=utf-8 和 -fexec-charset=GBK
这是影响最直接、无需改系统、不依赖插件的方案。关键在于两参数必须同时出现，缺一不可：
-
-finput-charset=utf-8：声明你的.cpp文件保存为 UTF-8（这是 VSCode 默认），让g++正确解析中文字符串字面量 -
-fexec-charset=GBK：强制g++把字符串常量以 GBK 编码写入最终的.exe，这样 Windows 终端（默认 CP936/GBK）才能原样显示 - 只加
-fexec-charset=GBK而源文件实际是 UTF-8，g++会把 UTF-8 字节当 GBK 解析，轻则报错，重则生成错误的二进制字符串 - 示例
args片段（放在tasks.json的args数组里）："args": [<br> "-g",<br> "${file}",<br> "-o",<br> "${fileDirname}\${fileBasenameNoExtension}.exe",<br> "-finput-charset=utf-8",<br> "-fexec-charset=GBK"<br>]
确保 .cpp 文件是 UTF-8 无 BOM 编码
VSCode 右下角状态栏点击编码名称（如 “UTF-8 with BOM” 或 “GBK”），选“通过编码重新打开” → 选 UTF-8，确认中文显示正常后再点“另存为”：
- 另存为时，“保存时编码”必须选
UTF-8，且**务必取消勾选“UTF-8 with BOM”** —— BOM（EF BB BF）是三个不可见字节，g++不识别，会导致#include头文件时报错 - 检查
settings.json是否干扰："files.encoding": "utf8"是对的；若存在"files.autoGuessEncoding": false，建议改为true，否则 VSCode 可能无法自动识别旧 GBK 文件
路径里不能含中文
这不是乱码问题，但会直接导致编译或调试失败，常被误判为编码问题：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
g++和gdb对中文路径支持极差，尤其gdb在中文路径下常崩溃，报错如During startup program exited with code 0xc0000135 - 哪怕所有编码都对，只要
tasks.json里${file}展开后路径含中文，g++就可能静默失败或报“找不到文件” - 解决方法：把项目移到纯英文路径下，例如
D:cpp-demo，而不是D:我的C++练习
别碰 chcp 65001（除非你清楚后果）
有人尝试在终端里执行 chcp 65001 切到 UTF-8，但这只是临时切换，且风险高：
- Windows 控制台对 UTF-8 支持不完整，某些 API（尤其是
gdb调试时）仍会 fallback 到 GBK，反而更不稳定 - 如果用了
chcp 65001，就必须确保整个链路全走 UTF-8：源码 UTF-8、g++输出 UTF-8（-fexec-charset=utf-8）、终端 UTF-8、字体支持 UTF-8 字形——任一环节断掉，乱码形态更难排查 - 对绝大多数 Windows 本地开发场景，用
-fexec-charset=GBK配合终端默认 GBK，才是最稳的组合
最容易被忽略的一点是：乱码看起来是“显示问题”，但根源永远在字节流生成那一刻——也就是 g++ 写入 .exe 的那一步。参数没配对、文件带 BOM、路径含中文，这三者任何一个存在，都会让后续所有补救（比如改终端、换字体）失效。
