1. 从两个让人抓狂的现场说起

如果你在Windows上写过C语言，大概率经历过这两个瞬间：第一个瞬间是代码里明明写的是printf("你好，世界\n");，编译运行之后终端里蹦出来的却是一串看不懂的方块或者问号；第二个瞬间是程序运行到scanf那一行，光标停在那里一动不动，你敲了字按回车，程序却像没听见一样直接跳过去了。这两个问题单独出现已经够烦人，偏偏它们经常一起出现，而且都跟VS Code的默认配置、Windows的终端编码、以及调试器的输入通道有关。

这篇内容就是围绕这三个纠缠在一起的问题展开的：中文乱码、scanf输入失效、以及怎么让程序在调试时用上真正的cmd窗口输出。我会把每个问题的根因拆开讲清楚，再给出可以直接照做的配置方案。适合的人群很明确：正在用VS Code写C/C++、被编码和输入问题卡住的初学者，以及想把这套环境彻底理顺、以后不再反复踩坑的开发者。文中涉及的所有配置我都实际跑过，参数和路径会写全，你照着改就行。

先说一个结论性的判断：这三个问题看起来是三个独立故障，实际上它们共享同一个底层原因——VS Code默认的集成终端、调试控制台、以及Windows系统控制台，三者的编码和输入机制并不一致。你只要理解了这三者的区别，后面所有配置都是顺理成章的。

2. 中文乱码的真正来源：不是VS Code的错

2.1 编码这条链路上到底有几个环节

很多人一遇到乱码就去改VS Code的设置，改了半天没用。原因是乱码从来不是单一环节的问题，它是一条链：源文件保存编码 → 编译器读取编码 → 可执行文件运行时输出编码 → 终端显示编码。这四个环节里任何一个和其他的对不上，就会乱码。

举个具体的例子。你在VS Code里新建一个文件，默认可能以UTF-8保存。你的源代码里写了中文字符串，这些字符在文件里是UTF-8字节序列。编译器（比如gcc）默认按UTF-8读取源文件，没问题。但是程序运行时，printf把这段UTF-8字节直接丢给Windows控制台，而Windows控制台默认的活动代码页是GBK（936）。GBK拿到UTF-8的字节去解码，自然就是乱码。

所以你会看到一个很典型的现象：同一个程序，在VS Code集成终端里是乱码，在外部cmd里可能正常，或者反过来。因为这两个终端的默认编码设置不一样。

2.2 用chcp命令快速验证问题出在哪

在动手改配置之前，先做一次诊断。打开你的终端，输入：

chcp

它会返回一个数字，比如活动代码页: 936。936就是GBK，65001就是UTF-8。你可以在VS Code集成终端和外部cmd里分别跑一次，对比结果。

如果集成终端是65001而外部cmd是936，那你的乱码问题基本就定位了：程序输出的编码和终端期望的编码不一致。这时候你有两个方向可选——要么让程序输出GBK，要么让终端接受UTF-8。我个人的建议是统一到UTF-8，因为这是跨平台的主流做法，以后换系统或者换工具都不用再改。

2.3 统一到UTF-8的完整配置

统一编码需要改三个地方，缺一不可。

第一处，源文件保存编码。在VS Code里按Ctrl+Shift+P，输入Change File Encoding，选择Save with Encoding，然后选UTF-8。更省事的做法是在设置里搜files.encoding，把它设成utf8。这样以后新建的文件默认就是UTF-8。

第二处，编译器读取编码。如果你用的是gcc，建议在编译参数里显式加上-finput-charset=UTF-8 -fexec-charset=UTF-8。这两个参数的意思是：源文件按UTF-8读，执行时的字符串也按UTF-8编码。很多人只加第一个，结果运行还是乱，就是因为fexec-charset没设。

第三处，终端显示编码。在程序开头加一行：

system("chcp 65001");

这行代码的作用是在程序运行时把控制台代码页切到UTF-8。注意它要放在任何中文输出之前。如果你用的是Windows的cmd，还需要把字体换成支持中文的字体，比如Consolas配合Lucida Console，或者直接用新宋体，否则即使编码对了，字形也可能显示成方块。

提示：system("chcp 65001")在部分环境下会让终端出现一个短暂的闪烁或者清屏，这是正常现象。如果你介意，可以在VS Code的settings.json里给集成终端设置启动参数，让它一开始就是UTF-8，而不是在程序里切。

2.4 一个容易被忽略的坑：BOM头

还有一个隐蔽的乱码来源是BOM（字节顺序标记）。有些编辑器保存UTF-8时会自动加BOM，而gcc对带BOM的源文件处理并不总是友好，可能导致第一行代码报错或者中文注释乱码。检查方法是用十六进制查看文件开头，如果看到EF BB BF就是有BOM。VS Code底部状态栏的编码显示里，UTF-8 with BOM和UTF-8是两种不同的状态，点一下可以切换。建议统一用不带BOM的UTF-8。

3. scanf为什么在VS Code里“失灵”

3.1 集成终端和调试控制台是两套输入通道

scanf失效这个问题，十有八九是因为你按了F5调试，而VS Code默认把程序输出和输入都接到了“调试控制台”（Debug Console）。这个调试控制台是VS Code自己实现的一个面板，它只负责显示调试器的输出，并不完整支持标准输入。也就是说，程序在等scanf的时候，你在调试控制台里敲字，这些字根本传不到程序的标准输入流里。

而如果你不是按F5，而是直接在集成终端里用gcc编译再./a.exe运行，scanf通常是正常的。这就是为什么很多人会发现“直接运行没问题，一调试就出问题”。

3.2 让调试时的输入走集成终端

解决办法是改调试配置。打开.vscode/launch.json，找到你的调试配置，加上或者修改这一项：

"console": "integratedTerminal"

这一行的意思是：程序运行时使用VS Code的集成终端，而不是调试控制台。集成终端是一个真正的终端模拟器，标准输入输出都正常，scanf就能收到你敲的内容了。

如果你希望用外部cmd窗口，可以改成：

"console": "externalTerminal"

这样每次调试会弹出一个独立的cmd窗口，输入输出都在那个窗口里。两种方式各有优劣，我在下一节会详细对比。

3.3 scanf本身的几个经典陷阱

配置改对了之后，还有几个scanf自身的坑要避开，这些和VS Code无关，但经常被误认为是环境问题。

第一个坑是scanf("%d", &n)后面跟scanf("%c", &c)。第一个scanf读走数字后，回车符还留在输入缓冲区里，第二个scanf会直接读到那个回车，看起来就像“跳过了输入”。解决办法是在两个scanf之间加一句getchar();把回车吃掉，或者用scanf(" %c", &c)，注意%c前面那个空格，它会跳过所有空白字符。

第二个坑是scanf的返回值。scanf返回成功读取的项数，很多人不检查它，导致输入格式不对时程序行为诡异。养成习惯：

if (scanf("%d", &n) != 1) { printf("输入格式错误\n"); return 1; }

第三个坑是字符串输入。scanf("%s", buf)遇到空格就停，想读一整行得用fgets。这个不算bug，但初学者经常在这里卡住。

4. 调试控制台、集成终端、外部cmd到底怎么选

4.1 三者的能力对比

这三个输出通道的差异，直接决定了你调试时的体验。我用一个表格把它们的关键能力列清楚：

从表里能看出来，调试控制台基本不适合任何需要输入的程序。它的定位是显示调试信息，不是当终端用。集成终端是大多数情况下的最优解，它就在VS Code窗口内，切换方便，编码配好后中文也没问题。外部cmd的优势在于它是最“真实”的Windows控制台，某些依赖控制台API的程序（比如用了conio.h里getch的）在集成终端里可能行为不一致，这时候就得用外部cmd。

4.2 配置externalTerminal时的一个细节

如果你选了externalTerminal，有个细节要注意：弹出的cmd窗口默认代码页还是936。也就是说，即使你程序里输出了UTF-8，这个窗口还是可能乱码。解决办法有两个，一是在程序里加system("chcp 65001")，二是在launch.json里通过args或者环境变量提前设置。我一般用第一种，简单直接。

另外，外部cmd窗口在程序结束后默认会立刻关闭，你来不及看输出。可以在程序末尾加system("pause")，或者在launch.json里配置"externalConsole": true配合调试器的暂停行为。不过system("pause")依赖Windows，跨平台代码里要小心。

4.3 我的实际选择

我自己的习惯是：日常开发用集成终端，遇到输入相关的诡异问题临时切外部cmd验证。这样既能享受集成终端的便利，又能在需要的时候排除终端模拟器带来的干扰。launch.json里我通常保留两个配置，一个用集成终端，一个用外部终端，需要时在调试下拉框里切换。

5. 一套可以直接抄的完整配置

5.1 tasks.json：编译参数里把编码钉死

先看编译任务。在.vscode/tasks.json里，关键是args数组：

{ "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "gcc", "args": [ "-g", "-finput-charset=UTF-8", "-fexec-charset=UTF-8", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "group": { "kind": "build", "isDefault": true } } ] }

这里-g是为了生成调试信息，两个charset参数是为了编码统一。注意输出路径用了Windows的反斜杠，如果你在别的系统上，改成斜杠即可。

5.2 launch.json：让输入走对通道

再看调试配置：

{ "version": "0.2.0", "configurations": [ { "name": "调试（集成终端）", "type": "cppdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "console": "integratedTerminal", "MIMode": "gdb", "miDebuggerPath": "gdb.exe", "preLaunchTask": "build" }, { "name": "调试（外部cmd）", "type": "cppdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": true, "console": "externalTerminal", "MIMode": "gdb", "miDebuggerPath": "gdb.exe", "preLaunchTask": "build" } ] }

两个配置的区别就在console和externalConsole这两项。preLaunchTask指向tasks.json里的build，这样按F5时会先编译再调试，省得手动编译。

5.3 settings.json：把默认编码和终端行为定下来

最后是工作区设置：

{ "files.encoding": "utf8", "files.autoGuessEncoding": false, "terminal.integrated.defaultProfile.windows": "Command Prompt", "terminal.integrated.profiles.windows": { "Command Prompt": { "path": "C:\\Windows\\System32\\cmd.exe", "args": ["/K", "chcp 65001"] } } }

这里files.encoding设成utf8，autoGuessEncoding关掉避免VS Code自作聪明猜错编码。终端配置里，我给cmd加了/K chcp 65001，意思是启动终端时自动切到UTF-8。这样即使程序里没写system("chcp 65001")，集成终端本身也是UTF-8的。

注意：chcp 65001在某些老版本的Windows上会让cmd的某些功能异常，比如批处理里的中文路径。如果你遇到这种情况，把终端配置里的args去掉，改回在程序里单独处理编码。

6. 排查乱码和输入问题的通用思路

6.1 先分离变量，再逐个击破

遇到乱码或者输入问题时，最忌讳的是同时改好几个地方，改完不知道是哪个起了作用。正确的做法是分离变量。

判断乱码来源时，先写一个最简单的程序：

#include <stdio.h> int main() { printf("test 测试\n"); return 0; }

然后分别在集成终端、外部cmd、以及直接双击exe运行三种方式下看结果。如果只有一种方式乱码，问题就在那个终端的编码设置上；如果全都乱码，问题在编译参数或者源文件编码上。这一步能把问题范围缩小一大半。

判断scanf问题时，同样先写最小复现：

#include <stdio.h> int main() { int n; printf("请输入一个数字："); scanf("%d", &n); printf("你输入的是：%d\n", n); return 0; }

如果直接运行正常、调试不正常，那就是调试通道的问题，改console配置。如果直接运行也不正常，那就要检查是不是输入缓冲区的问题，或者是不是程序根本没编译成功、跑的是旧的exe。

6.2 几个我踩过的具体坑

第一个坑：改了launch.json但没生效。原因是VS Code可能缓存了旧的调试配置，或者你改的是用户级的launch.json而不是工作区级的。确认方法是看调试配置下拉框里显示的名字是不是你改的那个。改完最好重启一下VS Code。

第二个坑：preLaunchTask的名字对不上。tasks.json里的label必须和launch.json里的preLaunchTask完全一致，大小写敏感。对不上时按F5会提示找不到任务，程序用的是上次编译的旧版本，于是你改了代码却没效果，误以为是编码问题。

第三个坑：多个源文件时${file}只编译当前文件。如果你的项目有多个.c文件，用${file}只会编译当前打开的那个，链接时会报未定义符号。这时候要把args里的${file}换成${fileDirname}\\*.c，或者用Makefile。这个坑和编码无关，但经常和乱码问题混在一起，让人误判。

第四个坑：终端字体不支持中文。编码全对，但显示还是方块，这时候要检查终端字体。VS Code集成终端的字体在设置里搜terminal.integrated.fontFamily，设成Consolas, 'Microsoft YaHei', monospace这类带中文字体的组合。

6.3 关于编码问题的一个长期建议

如果你经常在不同系统之间倒腾代码，我的建议是从项目一开始就把编码统一到UTF-8，并且在项目根目录放一个.editorconfig文件：

root = true [*] charset = utf-8 end_of_line = lf insert_final_newline = true

这个文件会被很多编辑器自动识别，能避免团队成员之间因为编辑器默认编码不同而产生的乱码。VS Code需要装一个EditorConfig插件来支持，但装一次以后省心很多。

7. 把环境理顺之后的一些体会

这套配置我用了挺长时间，中间也反复调整过。最开始我也是遇到乱码就搜一下、改一下，下次换个项目又乱。后来把编码这条链路彻底理清楚，把launch.json和tasks.json固定成模板，新项目直接复制.vscode目录，就再没被这些问题绊住过。

有一个认知上的转变值得分享：scanf在调试时失灵，本质上不是scanf的问题，也不是VS Code的bug，而是“调试控制台”这个面板的设计定位导致的。它本来就不是给你做交互输入的。理解了这一点，你就不会再纠结于“为什么我的scanf没反应”，而是直接去改console配置。

还有一个细节，system("chcp 65001")虽然好用，但它会让程序依赖Windows。如果你写的代码以后要放到别的系统上跑，记得用条件编译包起来：

#ifdef _WIN32 system("chcp 65001"); #endif

这样在非Windows系统上这行会被跳过，不会报错。

最后说一个排查顺序上的经验：遇到乱码先看终端代码页，遇到输入问题先看调试通道，两个都排除了再去看代码本身。这个顺序能帮你省下大量在错误方向上折腾的时间。环境配置这种事，一次弄对，后面就是纯收益。