终端输出乱码本质是编码链路断在“程序输出编码 → 终端解码编码”这一环：c++程序以utf-8输出字节流（如e4 bd a0），但windows终端默认用gbk（代码页936）解码，导致错译为乱码，而非显示或字体问题。
终端输出乱码本质是编码链路断在了哪一环
VSCode终端里printf("你好")或std::cout 显示问号、方块、“锟斤拷”，问题不在代码写错了，也不在编译器没编译好，而在于：程序按某种编码（比如 UTF-8）输出字节流，终端却用另一种编码（比如 GBK 或 CP936）去解释。Windows 的 cmd 默认 code page 是 936，PowerShell 也常继承这个设置；而 VSCode 编辑器本身保存源码多为 UTF-8，gcc/g++ 编译时若不显式指定执行字符集，生成的可执行文件默认按 UTF-8 输出——两边对不上，必然乱码。
改 settings.json 里的终端启动参数最直接
Windows 下最稳定的做法是让终端启动时就切换到 UTF-8 模式，而不是靠环境变量或 shell 配置。编辑你的 settings.json，加这一段：
"terminal.integrated.shellArgs.windows": ["\/k", "chcp.com", "65001"]
注意几个细节：
-
\/k是 cmd 的参数，表示执行完命令后保持窗口打开（/k在 JSON 里要转义成\/k） -
chcp.com 65001强制将当前终端代码页设为 UTF-8 - 如果你用的是 PowerShell，应改用
"terminal.integrated.shellArgs.windows": ["-NoExit", "-Command", "chcp 65001"] - 别写成
chcp 65001 && your_shell—— VSCode 不支持 shell 链式命令，只认启动参数列表
编译参数也要同步，否则程序自己“说”的还是 GBK
即使终端设成了 UTF-8，如果 C/C++ 程序在编译时没告诉编译器“我源码是 UTF-8，运行时输出也按 UTF-8 解释”，它仍可能按系统默认（GBK）处理字符串字面量。对 MinGW/GCC，必须加：
-
-finput-charset=UTF-8：告诉编译器源文件编码是 UTF-8 -
-fexec-charset=UTF-8：告诉编译器生成的可执行文件，字符串字面量运行时按 UTF-8 解释并输出
对应到 code-runner.executorMap 配置里，C 和 C++ 的执行命令要类似这样：
"cpp": "cd $dir && g++ -finput-charset=UTF-8 -fexec-charset=UTF-8 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt"
漏掉 -fexec-charset=UTF-8 是常见坑点：你改了终端、改了 settings.json，但程序自己输出的仍是 GBK 字节，终端再怎么设 UTF-8 也救不回来。
别依赖自动猜测，手动确认当前终端 code page
改完配置别急着重启 VSCode，先验证终端是否真生效：
- 新开一个集成终端，输入
chcp，看返回是不是活动代码页: 65001 - 如果还是 936，说明
shellArgs没生效，检查 JSON 格式有没有逗号错、引号没闭合 - 如果
chcp报错，说明你用的是 PowerShell 但配了 cmd 参数，或者路径里有空格没加引号（不过 Windows 下chcp.com通常自带） - 注意：修改
settings.json后，已打开的终端不会自动刷新 code page，必须新开终端窗口
真正卡住人的地方往往不是“该不该设 UTF-8”，而是终端、编译器、源文件三者编码没对齐，且其中任意一环改了却不验证是否落地。每次调完，务必跑一句 chcp 和一个带中文的 printf，眼见为实。
