让VSCode像Dev-C++一样弹窗运行C程序：配置详解

1. 先说清楚：为什么会有这个需求，以及它到底在解决什么

写 C 程序的老伙计们，应该都有一段 Dev-C++ 的青春记忆。大学上机课、计算机二级备考、被指针和结构体折磨的夜晚，那个老旧的界面和“运行”按钮一点就弹出来的黑色控制台窗口，就是我们对“写代码”这件事最初的认知。后来工作了，或者接触开源社区以后，慢慢转向 VSCode，轻量、插件生态丰富、颜值高、跨平台，但有一个坎始终绕不过去——运行一个 C 程序，总感觉不对劲。

为什么不对劲？因为 VSCode 默认是在内置终端里运行程序的。你按下 Ctrl+F5，结果输出结果挤在编辑器下方那块窄窄的面板里，没有独立的窗口；想用 scanf 从键盘输入，交互起来特别别扭；程序一跑完，输出一闪而过，想看个结果还得截图或者拼命往上翻。最要命的是中文乱码，明明代码里写着 printf(“你好”)，终端里显示的却是一堆看不懂的字符。这些体验，用习惯了 Dev-C++ 那套“弹窗运行”逻辑的人，是真的很难接受。

我当初从 Dev-C++ 转 VSCode 的时候，在这上面折腾了整整两天。上网搜解决方案，搜出来的全是“在 VSCode 里配置 C/C++ 环境”“安装 MinGW”“改 launch.json”之类的老生常谈，没有一个正面回答“怎么让它弹窗运行”这个问题。后来自己翻文档、试参数、踩坑，才搞明白 VSCode 其实完全具备“调起外部控制台窗口”的能力，只是默认没有配置好，或者说，官方文档给的示例压根没往这个方向引导。

这篇文章我就把整套方案写清楚，从最基本的原理讲到可以直接复制粘贴的配置，最后再把常见问题一网打尽。适合谁看？刚用 VSCode 写 C 语言、正在跟内置终端和乱码问题死磕的新手；也适合被公司文档逼着换编辑器、但心里还惦记着 Dev-C++ 那种干脆利落感的老手。解决什么问题？一句话总结：让 VSCode 在你按下运行键之后，弹出一个独立、干净的黑色控制台窗口来跑你的 C 程序——和 Dev-C++ 一模一样。

2. 理清思路：VSCode 和 Dev-C++ 的运行机制到底差在哪

2.1 两者的“工作流”差异才是根本原因

先说清楚一个底层逻辑。Dev-C++ 是集成开发环境，自带编译器（通常是 MinGW 或者 TDM-GCC），它的运行按钮背后做了一整套动作：调用编译器生成 exe、然后使用system("cmd /c pause")之类的机制在新开的控制台宿主窗口中加载并执行这个 exe、程序结束后按任意键暂停。整个过程对用户是透明的，你看到的就是一个窗口弹出来，程序在里面跑，跑完停在结果页面上。

VSCode 本质上是编辑器，不是 IDE。它运行 C 程序靠的是两件事：一个是tasks.json里定义的任务（负责编译），另一个是launch.json里的调试或运行配置（负责执行）。默认情况下，VSCode 会调用其内置的“集成终端”来显示运行结果。这个终端是从编辑器内部启动的，它不是在操作系统层面新建了一个独立进程窗口，而是把输出“托管”到了 VSCode 的 UI 面板上。于是就会出现那堆问题：交互输入别扭、中文编码不匹配、程序结束终端进程直接返回提示符导致输出丢失。

这就是最核心的认知点：想让 VSCode “弹窗”运行 C 程序，本质上是让 VSCode 放弃内置终端作为执行宿主，而是通过调用系统命令（Windows 下就是 cmd 或 PowerShell）新建一个独立窗口，然后把编译好的 exe 丢进去运行。搞清楚这一点，后面所有配置都不用死记硬背，你能自己推导出来。

2.2 为什么很多人第一波尝试就翻车

网上很多教程一上来就让你装 Code Runner 插件。Code Runner 确实能一键运行，但它默认还是在集成终端里跑，顶多帮你自动把编译和运行两步合成一步，并不能实现“弹独立窗口”。有人就在这里面绕了好久，装完插件、点运行，发现还是没弹窗，以为是配置问题，折腾半天一无所获。

还有人走上了改 launch.json 的路子，比如把externalConsole参数设成true。这个参数确实是用来控制是否弹出外部控制台窗口的，但注意，它是给调试模式（F5 启动的调试会话）用的，不是给普通的“运行”用的。如果你只是按 Ctrl+F5（不调试运行），或者干脆直接跑 tasks.json 里的任务，这个参数根本不会生效。我第一次试的时候就犯了这个错误，改完 launch.json 里外没反应，后来才意识到自己用错了入口。

搞清楚这两点之后，方案其实就很清晰了。我们有两个方向可以走，一是修改 tasks.json 里的任务定义，让“生成”任务顺带调起外部窗口；二是用 cmd 的/c start命令在集成终端里间接启动一个新窗口。这两个方向我实际都测过，各有优劣，下面分开讲。

3. 环境准备：先确认你的“地基”牢不牢

在折腾“弹窗”这个事之前，先把最基础的环境检查一遍。我见过太多人卡了半天才发现，自己的 VSCode 根本连编译器都没配置好，那后面的一切都是空中楼阁。

首先是 C/C++ 扩展。打开 VSCode 的扩展面板，搜 “C/C++”，认准微软出的那个，作者显示是 Microsoft，图标是个蓝底 C 字。这个插件提供语法高亮、智能提示、调试支持和 tasks.json、launch.json 的自动生成，是整个流程的基础。我建议你在没有它的情况下不要进行任何操作，因为没有它会非常痛苦。

然后是编译器。Windows 上最常用的是 MinGW-w64（GCC 的 Windows 移植版）。下载安装好以后，关键一步是配环境变量。把编译器所在的 bin 目录，通常是类似C:\mingw64\bin这样的路径，加入系统 PATH 环境变量。验证方法：开一个新的命令提示符窗口，输入gcc --version，能显示版本号就说明配置成功。注意是开新窗口，因为环境变量改了以后，已经打开的窗口不会自动刷新。

还有一件事，建议顺手把 VSCode 完全关掉再重新打开。很多人配完环境变量后，VSCode 还是报“找不到编译器”，就是因为没重启。这个坑太常见了，我大学室友就是在这一步摔了跟头，愣是搞了两小时，最后发现换个新窗口就好了。

检查完这两样，按Ctrl+Shift+P打开命令面板，输入 “C/C++: Edit Configurations (UI)”，进入编译器路径设置页面，确认 Compiler path 指向你的 gcc.exe。如果一切正常，这一步会生成一个c_cpp_properties.json文件，里面记录的路径就是之后所有操作的基础。地基牢了，咱们才开始盖房子。

4. 核心改造：亲手编写 tasks.json 让程序弹窗运行

4.1 认识 tasks.json 的编译任务模板

正常情况下，当你第一次在一个 .c 文件上按 Ctrl+F5，或者从菜单栏选择“终端 -> 配置默认生成任务”，VSCode 会自动生成一个 .vscode 文件夹，里面包含 tasks.json 和 launch.json。tasks.json 里的内容大概是这样的：

{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: gcc.exe 生成活动文件", "command": "C:\\mingw64\\bin\\gcc.exe", "args": [ "-fdiagnostics-color=always", "-g", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": { "kind": "build", "isDefault": true }, "detail": "调试器生成的任务。" } ] }

这个任务做的事情很简单：用 gcc 把当前打开的 .c 文件编译成同目录下同名 .exe。${file}是当前文件的完整路径，${fileDirname}是当前文件所在目录，${fileBasenameNoExtension}是文件名不含后缀的部分。这些都是 VSCode 内置的变量，理解它们对后面改造很重要。

注意这里我只写了编译任务，没有写运行任务。VSCode 默认的 Ctrl+F5 流程是：先执行编译任务，然后通过 launch.json 的配置启动调试器来运行程序。我们的目标是要在这条链路上插入一个“打开外部窗口”的环节。

4.2 旧方案：在 tasks.json 里添加 command 调用外部控制台

我最早折腾出来的方案，是在编译任务后面再加一个运行任务，用 VSCode 的command类型任务来调起外部 cmd 窗口。思路是：先编译生成 exe，然后调用cmd.exe /c start去启动一个新的命令提示符窗口，窗口内的命令就是运行那个 exe。这样就能实现“弹窗运行”的效果。

完整配置如下（可以直接复制，但建议看完后面的解释再动手）：

{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: gcc.exe 生成活动文件", "command": "C:\\mingw64\\bin\\gcc.exe", "args": [ "-fdiagnostics-color=always", "-fexec-charset=UTF-8", "-g", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": { "kind": "build", "isDefault": true }, "detail": "调试器生成的任务。" }, { "label": "Run C Program in External Window", "type": "shell", "command": "cmd /c start \"C Program\" cmd /k \"chcp 65001 >nul && \"${fileDirname}\\${fileBasenameNoExtension}.exe\"\"", "dependsOn": "C/C++: gcc.exe 生成活动文件", "group": { "kind": "build", "isDefault": true } } ] }

这里我加了一个关键参数-fexec-charset=UTF-8，它的作用是告诉编译器，生成的 exe 里字符串常量按 UTF-8 编码处理。这样配合新窗口里执行的chcp 65001（把控制台代码页切换成 UTF-8），就能从根源上解决中文乱码问题。这个参数太重要了，后面单开一节详细讲。

第二个任务就是核心：它是一个shell类型的任务，意味着 VSCode 会调用系统 shell 来执行command里的命令。我拆开来解释一下这条命令的含义。

cmd /c start "C Program" cmd /k "chcp 65001 >nul && \"${fileDirname}\\${fileBasenameNoExtension}.exe\""

这条命令初看像天书，一层层拆开就明白了。最外层cmd /c，表示我要启动一个新的 cmd.exe 进程来执行后面的整串命令；接下来的start "C Program"是 cmd 的一个内部命令，专门用来“新开一个窗口”，后面引号里的C Program是给这个新窗口随便起的标题；再后面的cmd /k表示这个新窗口里也要跑一个新的 cmd 进程，/k参数的意思是执行完命令后不退出（保持窗口开启），方便我们看运行结果；然后再一层引号里，先执行chcp 65001 >nul把代码页切到 UTF-8，注意>nul是把这段命令的输出吞掉，不让它在窗口里刷屏；&&表示前一条命令成功后再执行后面那条，也就是运行我们的 exe。

dependsOn字段的意思是：这个运行任务会先触发它依赖的编译任务，也就是先生成 exe，然后再执行自身命令。这样你只需要按一次快捷键，就能完成“编译 -> 弹窗运行”整条链路。

我这里用了一个技巧，把group都设成build且isDefault: true，这样在“终端 -> 运行生成任务”菜单里，两个任务会被归为一组，快捷键 Ctrl+Shift+B 会直接蹦出任务选择器，选择那个 Run 任务就能跑。

这个方案我用了一段时间，实测可用，但也有两个小毛病。一是从集成终端里看命令输出，会看到一堆 cmd 的启动信息，虽然不影响结果，但不够清爽；二是在某些 Windows 版本上，start嵌套 cmd 的引号匹配偶尔会出问题，导致窗口一闪而过。后来我研究出了更稳的第二套方案。

4.3 新方案：直接修改 launch.json，通过 externalConsole 弹窗运行

我后来发现，其实可以更优雅地解决这个问题——既然externalConsole参数本来就是为了调起外部窗口设计的，那我们就好好利用它。只不过别把它放在调试配置里，而是建立一个专门用于“运行”的配置。具体做法：在 launch.json 里增加一个配置，externalConsole设为true，然后把program指向编译好的 exe。这样按 F5 时，VSCode 会先执行 preLaunchTask（编译），然后直接弹出一个独立的控制台窗口来运行程序。

修改后的 launch.json 是这样（如果文件不存在，可以从命令面板执行“Debug: Open launch.json”创建）：

{ "version": "0.2.0", "configurations": [ { "name": "Run in External Window", "type": "cppdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": true, "MIMode": "gdb", "miDebuggerPath": "C:\\mingw64\\bin\\gdb.exe", "preLaunchTask": "C/C++: gcc.exe 生成活动文件", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ] } ] }

这里externalConsole: true是关键。当这个值为 true 时，调试器不会把程序挂到 VSCode 内置终端上，而是调用系统的控制台宿主来创建独立窗口。对于不使用调试器、只是想“跑一下看结果”的场景，这个窗口点击后还会保留住程序的输出。

配套地，tasks.json 里也简化了，不需要那个花里胡哨的 shell 任务，只要保留一个干净的编译任务就行。整体流程变成：按 F5 -> VSCode 执行编译任务 -> 编译成功 -> 弹出一个新窗口运行 exe -> 程序等待输入 / 输出结果 -> 按任意键窗口关闭（因为 VSCode 的弹窗模式会挂起窗口）。

我第一次这么配置以后，体验好了非常多，特别是调试功能还保留着——如果你的运行有问题，可以在 VSCode 内置调试器里打断点排查，而日常直接运行则用弹窗模式，两不耽误。这也是我更推荐这个方案的原因。

4.4 编译命令里必加的编码参数，防乱码的根源在这一行

很多人在 VSCode 里写 C 程序遇到中文乱码，第一反应是改窗口的代码页，或者改 VSCode 的编码设置，改了半天还是乱。核心原因没搞明白：乱码发生在两个环节，一个在“源代码 -> 可执行文件”的编译环节，另一个在“可执行文件 -> 控制台窗口”的显示环节，光改显示端不解决根本问题。

Windows 下 VSCode 默认的文件编码是 UTF-8，而 GCC（特别是 Windows 版）编译时默认把源代码当成当前系统本地代码页（通常是 GBK，也就是 CP936）来读。于是源代码里用 UTF-8 存的中文字符串，被 GCC 按 GBK 的规则解释成了一个一个错的字节序列，编译进 exe 后自然就是乱码的根源。同理，printf 里直接写死的汉字，在 exe 里其实存的是被错误编码过的字节。

解决办法是加编译参数-fexec-charset=UTF-8，告诉 GCC：源码里的字符常量请按 UTF-8 编码存入 exe。配合运行时把控制台的显示代码页切到 65001（也就是 UTF-8），两个环节都对齐了，中文才能正常显示。

如果你用的是第 4.2 节的 shell 任务方案，窗口里的chcp 65001 >nul就是做这个事的；如果你用 4.3 节的 launch.json 方案，你需要在environment里加一项，或者在自己的程序开头先用 system 函数执行一下chcp 65001，更直接的做法是在program的 cwd 里启动前先调用system("chcp 65001 >nul"), 但我不建议在代码里加这种硬编码，更推荐在 launch.json 的 environment 字段里设置{"name": "LANG", "value": "zh_CN.UTF-8"}，实测也能部分解决。最稳妥的办法其实是两条腿走路：编译参数加上-fexec-charset=UTF-8，运行时在新窗口里执行chcp 65001。

5. 手把手实操：从零配置一个能弹窗运行的 C 项目

5.1 新建工作目录和 Hello World 测试文件

空讲理论没意思，我这边直接带你把整套流程走一遍，从新建文件到最后成功弹窗，一步一步来。为了演示方便，我建了一个专门的目录，比如E:\CWorkspace\PopupDemo，然后新建一个源文件hello.c，代码如下：

#include <stdio.h> int main() { printf("你好，世界！\n"); printf("如果你能看到这个窗口，说明弹窗配置成功了。\n"); printf("请输入一个数字，测试一下输入功能：\n"); int n; scanf("%d", &n); printf("你输入的是：%d\n", n); system("pause"); return 0; }

注意这里的system("pause")。在 Dev-C++ 里，你不需要写这行，因为它的运行窗口自带“按任意键继续”的暂停机制。但 VSCode 的外部弹窗在程序正常结束后，窗口可能自动关闭，所以我们需要在程序的末尾手动加一个暂停，这样运行完还能看到结果。这个习惯建议保留，至少在弹窗方案里非常实用。

5.2 创建 tasks.json 和 launch.json（完整可复制配置）

在 VSCode 里打开这个文件夹，然后按Ctrl+Shift+P，输入 “C/C++: Add Debug Configuration” 或者直接 F5，VSCode 会提示选择环境，选 C++ (GDB/LLDB)，生成默认的配置。然后把上面 4.2 和 4.3 的代码分别覆盖到.vscode/tasks.json和.vscode/launch.json里。切记tasks.json 里的编译任务必须保留，launch.json 里的preLaunchTask指向的任务名必须和 tasks.json 里的 label 完全一致，字母大小写都不能错。

我踩过一个坑：把 label 里的C/C++: gcc.exe 生成活动文件复制到 preLaunchTask 时，因为冒号后面多了一个空格，导致 VSCode 找不到任务，弹窗运行直接失败。这类“隐性错误”编译器不会报，VSCode 也不给提示，查起来特别费劲。

此外，如果你装的编译器路径不同，记得改 tasks.json 里的command和 launch.json 里的miDebuggerPath。我这里的路径是C:\mingw64\bin\，你要是装在 D 盘或者其他目录，按实际情况修改。

5.3 配置好后怎么运行，快捷键和菜单操作一览

配置好之后，有三种方式可以启动我们的“弹窗运行”流程：

1. 按 F5：这是调试模式，会走 launch.json 的配置，触发 preLaunchTask 编译，然后弹窗运行程序，同时保留完整的调试能力（断点、变量监视都可能用）。
2. 按 Ctrl+F5：这是不调试直接运行，但它会走内置终端，不是弹外部窗口，所以这个快捷键反而不适合我们用。这点容易混淆，务必注意。
3. 按 Ctrl+Shift+B：这是“运行生成任务”，会打开任务选择器，你选那个 Run in External Window 对应的 shell 任务（如果你用的是 4.2 方案），或者直接选中编译任务。

我最推荐的日常用法是 F5：它最接近 Dev-C++ 里“编译并运行”的肌肉记忆。按一下，VSCode 先编译，编译没问题就弹窗，窗口里程序跑起来，输入输出都自由。如果有语法错误，问题面板会直接列出，不用等到弹窗。

5.4 验证弹窗成功的关键观察点

配置完成后，按 F5，观察有没有以下现象。第一，VSCode 底部状态栏会先显示“正在构建”，一秒左右后消失；第二，屏幕正中央（或脱离 VSCode 的位置）弹出一个黑色窗口；第三，窗口里第一行显示“你好，世界！”，第二行显示提示信息，程序等待输入。这三个现象同时出现，说明弹窗运行配置成功。

如果窗口一闪而过，或者什么都看不到，就去看“终端”面板里有没有报错，常见错误集中在 gcc 路径不正确、任务名不匹配、编译失败这几种。下一节我把常见问题整理成速查表。

6. 日常使用中的常见问题排查与避坑指南

6.1 弹窗一闪而过，根本看不见运行结果

这是最高频的问题，原因通常有三个。第一个是编译失败：程序本身有语法错误或者链接错误，exe 根本没生成，VSCode 的弹窗机制就会直接失败。第二种是system("pause")缺失，程序跑完之后，窗口跟着进程一起退出，肉眼根本来不及看。注意system("pause")在 4.2 方案的cmd /k模式下其实可以省略，因为/k会保持窗口存活，但如果你用的是 launch.json 的 externalConsole 模式，system("pause")基本是必须的。第三种是start嵌套问题，就是 4.2 方案里引号匹配出错、cmd 解析命令失败，这种情况建议换用 4.3 的新方案。

从 pragma 角度说，我建议无论如何都在代码末尾加system("pause")，这是最保险的。有些 IDE 或者调试器会在程序结束后自动暂停，但依赖外部控制台时，自己动手最可靠。

6.2 窗口弹出来了但中文全是乱码

中文乱码我在前面已经详细讲了原理，这里直接说排查步骤。第一步，确认 tasks.json 的编译参数里有-fexec-charset=UTF-8，没有这个参数，编译出来就是按 GBK 解释的错字节，怎么改窗口代码页都没用。第二步，确认窗口里执行了chcp 65001，在 4.2 方案里这是写进命令里的，在 4.3 方案里，如果你没有手动设置环境变量，建议在代码最前面调用一次system("chcp 65001 >nul")，或者直接在 launch.json 的environment字段加一个LANG=zh_CN.UTF-8。第三步，确认 VSCode 本身的文件编码是 UTF-8：右下角状态栏点击编码按钮，选择“通过编码重新打开”，选 UTF-8。三步全做完，乱码基本绝迹。

我还要提醒一个隐蔽问题：如果你用记事本手动改过源码，记事本在另存时有很大的概率把编码存成 ANSI（GBK），那就和 VSCode 的 UTF-8 又冲突了。建议所有修改都在 VSCode 内部完成，保持一致。

6.3 按 F5 提示找不到任务或找不到 gcc

这个错误通常是因为 launch.json 里的preLaunchTask名称和 tasks.json 里的任务 label 不一致，最常见的是大小写、空格、全角半角符号不匹配。在 JSON 里不要写全角冒号或者中文引号，一个不小心就是 bug。还有一种情况是 tasks.json 语法出错，比如缺少逗号或者括号不匹配，VSCode 会提示红色波浪线或者直接报“无法分析 JSON”。遇到这种，建议把 tasks.json 内容删了重写，不要手工修，JSON 的括号嵌套很容易看得晕。

另外，gcc 路径找不到的问题，除了环境变量之外，还有一种可能：你装的是 Dev-C++ 自带的编译器（通常埋在老旧的 MinGW32 路径下），那个版本太老而且路径里可能有空格。强烈建议单独装一个官方版 MinGW-w64，装的时候记得选 x86_64 架构、win32 threads、seh 异常处理模型，这几个选项影响兼容性。路径里不要有中文和空格——这一点太重要了，我曾经在C:\Program Files (x86)下面装 MinGW，结果折腾了一整个下午的路径转义。

6.4 我一按 Ctrl+F5 还是在内置终端里跑，怎么回事

好问题，这个坑尤其隐蔽。Ctrl+F5 在 VSCode 的默认键位里绑定的是“运行而不调试”，它使用的执行机制和 F5（调试）不一样。F5 走 cppdbg 调试器，externalConsole 参数生效，所以能弹窗；Ctrl+F5 走的是 VSCode 自己的运行逻辑，很多时候会直接复用集成终端，externalConsole 根本无济于事。如果你习惯了 Ctrl+F5，可以自己改键位绑定，把它重映射到 F5 的调试启动上；或者干脆养成用 F5 的习惯。我的建议是直接改键位，打开键盘快捷方式（Ctrl+K Ctrl+S），搜 “run without debugging”，把它的绑定删掉或者改成别的，避免习惯性误触。

另一种常见误解是：装了 Code Runner 插件后，它的运行按钮也是走内部终端，跟 externalConsole 无关。如果你既想要 Code Runner 的一键体验、又想要外部弹窗，需要单独配置该插件的自定义运行命令，但个人认为没必要——F5 已经足够好用了。

6.5 常见问题速查表

为了你以后排查方便，我把上面这些典型问题整理成一个速查表：

7. 关于这个方案的反思与延伸建议

我实际操作了相当长一段时间以后，发现这套“弹窗运行”方案并不只是“折腾一下让体验变好”这么简单，它背后反映了一个更实际的问题：不同背景的程序员进入同一个编辑器后，对“运行”这件事的心理预期差异巨大。Dev-C++ 的窗口模式天然适合学习阶段——因为那个阶段你大部分时间在写控制台程序，交互都是标准输入输出，一个独立的黑窗口反而是最直观的反馈。而 VSCode 的集成终端偏工程化，它更适合处理日志输出、多任务并行、环境变量的统一管理这些复杂场景。

所以在团队里，如果有刚转过来的新手，我通常建议他们先用本文的 4.3 方案过渡几周，把精力聚焦在语言本身，而不是适配编辑器上。等他们慢慢上手以后，再引导尝试集成终端、多任务、调试器这些高级功能，会发现这些工具各有适用场景，并不是什么非此即彼的东西。

还有一个延伸思路：其实这个操作同样适用于运行 Python、Java 甚至 Node.js 脚本。比如你想让一个 Python 程序也弹窗运行，只需要在 tasks.json 里构造类似命令：cmd /c start python 你的脚本.py，等于是举一反三。VSCode 的 tasks 系统本质上就是一个通用任务执行器，不只是为 C/C++ 服务的，学会这一招，其它语言也能玩转。

我个人的习惯是把 tasks.json 和 launch.json 这两个文件加入项目自带的配置文件版本库里，这样团队里任何人克隆项目下来，按一个 F5 就能获得一致的体验，不用每个人各自折腾一遍。这是很多 VSCode 项目欠缺的“开箱即用”意识，建议大家都养成的习惯。

最后再分享一个小技巧：如果你发现弹窗窗口的位置每次都不一样，可以在代码里调用MoveWindow或SetConsoleTitle来固定位置和标题，虽然这个纯粹是锦上添花、不影响功能，但当你盯着屏幕调程序调了一整天，有一个位置稳定、标题醒目的控制台窗，浮躁的心情会舒缓不少。技术在细节里体现温度，配置这种东西讲究的就是贴合自己的习惯——你现在可以把 VSCode 改造成你最顺手的样子了。