很多人对 VS Code 的第一课不是写代码而是被怎么运行卡住。我还记得当年在 Windows 上写完第一个 C 的 hello world顺手按了 F5编辑器没有输出结果反而弹出一个让我创建 launch.json 的提示框接着是一堆 program、args、miDebuggerPath 的字段我需要先搞懂编译产物在哪、调试器在哪才能看到一行 Hello World。对老手这是五分钟的事对刚上手的人这就是劝退。Code Runner 这个 VS Code 插件解决的正是这段落差。它做的事情说起来很简单把你本来要在终端里手敲的一整条命令——编译、链接、再执行——压缩成一次 CtrlAltN。它支持几十种语言装完即用不侵入你的调试配置也不需要你理解 launch.json 的结构。它不是调试器也从来没打算做构建系统但在我就想看一眼这段代码跑出来是什么结果这个场景里它的效率高得离谱。下面这些内容是我用了好几年 Code Runner、踩过乱码、踩过读取不到输入、踩过相对路径跑飞之后攒下来的包含配置细节、故障排查链路以及那些官方 README 里不会写、但实际开发中一定会遇到的坑。1. Code Runner 到底省掉了哪几步1.1 一次运行背后的完整链路在讨论配置之前得先明确一件事任何语言的运行都不是一步操作而是好几步。以 C 为例你按下运行键之后实际发生的事情是这样的——先把源文件编译成目标文件再把目标文件链接成可执行文件然后由操作系统加载这个可执行文件最后把它的标准输出回显到某个界面里。Python 看似只有一步其实也有找到解释器进程 → 把文件路径作为参数传进去 → 捕获子进程的 stdout/stderr → 回显这么多环节。大多数 IDE 把这些环节藏在了一个按钮后面Run这个词把复杂度给掩盖了。问题是当某一环出错的时候报错信息指向的往往不是按钮而是中间那几十个字符的命令。Code Runner 的价值就在于它把这整条命令明确地、可编辑地暴露给你。你按 CtrlAltN它做的事情就是拿着一条字符串去执行,这条字符串默认长这样cpp: cd $dir g $fileName -o $fileNameWithoutExt $dir$fileNameWithoutExt一旦你能读懂这行字符串你就能明白我明明改了代码为什么输出还是旧的为什么报错说找不到某个 .exe这类问题的根源在哪。这是 Code Runner 最被低估的一点——它不只是省了打字它把运行这件事的每个环节都摆在了明面上。另外要清楚 Code Runner 的边界它以文件为单位工作一次处理一个源文件。它不知道你的项目用 CMake、Maven 还是 pnpm也不知道你的模块之间有什么依赖。所以它适合脚本、算法题、单文件小工具、教学示例不适合一个有成百上千个源文件的工程。1.2 OUTPUT 面板与集成终端两种模式决定了你后面会遇到什么Code Runner 有一个开关叫code-runner.runInTerminal它决定了输出落在哪里而这个开关的取值会直接决定你后面会遇到哪一类问题。默认状态下它是false命令的输出会写进一个叫 OUTPUT 的面板里。OUTPUT 面板的优点很直观它是只读的、干净的、不会因为你手滑敲了几个字符而污染输出每次运行还会自动清屏由code-runner.clearPreviousOutput控制默认true。做题、看打印结果这种模式最舒服历史输出不会堆积。但它有一个致命的短板OUTPUT 面板不是终端它没有标准输入。任何需要从键盘读数据的代码——C 的scanf、C 的cin、Python 的input()、Java 的Scanner——在这个模式下都会卡住光标闪啊闪程序像死了一样。这不是 bug是设计使然。把code-runner.runInTerminal改成true之后命令会送到 VS Code 的集成终端里执行。这时候标准输入可用颜色转义序列比如 Python 里用 colorama 打的彩色日志也能正常渲染而不是在 OUTPUT 面板里显示成一堆[0;32m这样的乱码。代价是终端里会留下大量历史输出而且如果你手动在终端里敲了命令下一次 Code Runner 的输出可能被夹在你的输入之间看着很乱。我的做法是做题、写不需要交互的小脚本用 OUTPUT 面板一旦代码里有input()或者cin立刻切到终端。这比每次都去排查为什么我的程序卡住了要省事得多。1.3 装完 Code Runner 之后我第一时间改的三项插件市场里搜 Code Runner作者是 Jun Han装完之后设置项里搜code-runner能出来一长串。下面三项是我每换一台机器都会先改的。第一项code-runner.fileDirectoryAsCwd设为true。这个设置决定了程序运行时的工作目录。默认值是false也就是说程序的工作目录是 VS Code 打开的文件夹根目录而不是你那个源文件所在的目录。这会导致一个非常典型的困惑代码里写with open(data.txt)文件明明和 .py 在一个文件夹里却报 FileNotFoundError。把这项改成true工作目录就跟着文件走了。第二项code-runner.saveFileBeforeRun设为true。默认它其实是true但如果你手动关掉过或者用的是旧版本强烈建议确认一下。这个开关保证运行时自动保存当前文件避免出现我明明改了逻辑怎么还是旧结果的错觉——这种错觉排查起来特别费时间因为你会先怀疑编译器、怀疑缓存、怀疑插件最后才发现是文件没存。第三项code-runner.ignoreSelection设为true。Code Runner 有个行为如果你的编辑区里选中了一段文本按运行键它只会运行选中的那部分而不是整个文件。这个功能在做算法题时挺好用但在正常开发时是灾难——你可能只是随手选中了一行想复制结果按了运行跑出来一堆莫名其妙的报错。把它设成true之后无论选中什么都运行整个文件。2. executorMap 是 Code Runner 的心脏2.1 键、值与那八个可用变量code-runner.executorMap这个设置是 Code Runner 真正的核心。它的结构是一个 JSON 对象键是语言标识对应用 VS Code 识别的语言 ID比如python、cpp、java、javascript、go、rust值是要执行的命令字符串。值的部分最关键的是一些占位变量Code Runner 在执行前会把它们替换成真实路径。官方文档给出的变量一共八个我把它们和实际用途整理在一张表里变量名展开成什么典型用途$workspaceRoot当前工作区根目录的完整路径需要以项目根为基准时使用$dir当前文件所在目录带结尾斜杠拼可执行文件输出路径$dirWithoutTrailingSlash同上但不带结尾斜杠作为-I、-L等编译参数的目录$fullFileName当前文件完整路径交给解释器执行如 Python$fileName当前文件名带后缀传给编译器$fileNameWithoutExt文件名去掉扩展名生成可执行文件的名字、Java 类名$driveLetterWindows 盘符形如C:Windows 上处理跨盘路径$pythonPath当前选中的 Python 解释器路径解决虚拟环境不生效的问题这里有一个很多人没注意的点这些变量展开出来的路径可能包含空格。如果你的项目放在D:\My Projects\这种带空格的目录下那么g $fullFileName展开之后就会被命令行解析成两个参数编译直接失败。解决办法是给变量加上双引号写成g $fullFileName。Windows 上路径里带中文也是同样的道理虽然双引号解决不了编码问题但至少能保证参数不被拆断。2.2 默认命令里那些看不见的坑回到那条默认的 C 命令cpp: cd $dir g $fileName -o $fileNameWithoutExt $dir$fileNameWithoutExt拆开看三段。第一段cd $dir把工作目录切到源文件所在目录第二段编译并指定输出文件名第三段执行刚生成的产物。逻辑本身没问题但有几个隐含假设它假设g在 PATH 里、假设源文件是单文件、假设没有任何额外的编译参数。Python 那条默认命令里有个容易被忽略的-upython: python -u $fullFileName-u的意思是强制标准输出和标准错误不缓冲。别小看这个参数没有它的时候Python 的输出会先攒在缓冲区里程序正常结束才一次性吐出来。对于死循环或者长时间运行的程序你会看到程序明明在跑输出面板却一片空白然后开始怀疑是不是插件坏了。加上-uprint出来一条就显示一条。code-runner.showExecutionMessage这个设置控制的是每次运行前提示Code Runner 正在运行之类的信息。我一般关掉它因为 OUTPUT 面板里本来就有[Running] ...和[Done] exited with code0 in 0.28 seconds这两行标记能看出运行状态和耗时再额外弹一条消息纯属噪音。2.3 我自己在用的配置下面这份是我日常用的settings.json片段直接在用户设置里粘贴就能用。我把关键参数的含义都写在注释里了{ code-runner.runInTerminal: false, code-runner.saveFileBeforeRun: true, code-runner.fileDirectoryAsCwd: true, code-runner.ignoreSelection: true, code-runner.clearPreviousOutput: true, code-runner.executorMap: { python: python -u $fullFileName, cpp: cd $dir g -stdc17 -Wall \$fileName\ -o \$fileNameWithoutExt\ $dir$fileNameWithoutExt, c: cd $dir gcc -stdc11 -Wall \$fileName\ -o \$fileNameWithoutExt\ $dir$fileNameWithoutExt, java: cd $dir javac -encoding UTF-8 $fileName java $fileNameWithoutExt, javascript: node $fullFileName, go: go run $fullFileName, rust: cd $dir rustc $fileName -o $fileNameWithoutExt $dir$fileNameWithoutExt } }几点说明。C 那条我加了-stdc17和-Wall——前者是因为很多在线题解用了较新的语法不加标准编译不过后者是因为初学阶段最常见的 bug 就是变量未初始化、类型隐式转换把警告打开能提前发现一大半。编译器的输出文件名我加了引号防止文件名里出现空格或者中文导致输出路径被截断。Java 那条我加了-encoding UTF-8。这是被中文注释坑出来的经验Windows 上javac默认用系统编码读源文件如果你的源文件是 UTF-8 存的、里面有中文注释编译时会直接报编码 GBK 的不可映射字符。加上参数之后问题消失。go run和node这类本身就是解释执行的直接给完整路径就行不需要 cd。2.4 executorMapByGlob一个仓库里跑两套规则除了按语言配置Code Runner 还提供了code-runner.executorMapByGlob可以按文件路径通配符覆盖语言级的配置。这个功能知道的人不多但很实用。举个我自己的场景我在同一个仓库里既有普通的 .py 工具脚本又有一批必须带参数运行的脚本。普通脚本走默认的python -u $fullFileName带参数的那批我希望自动带上参数。这时候可以这样写code-runner.executorMapByGlob: { **/scripts/with_args/*.py: python -u $fullFileName --verbose --input data.json }注意匹配的键是相对于工作区的路径通配符写的时候要按你实际目录结构来。这个机制的好处是你不用为了带参数运行去搭一套 launch.json也不用每次在终端里手敲长命令。当然它只适合些固定的、参数几乎不变的脚本如果需要经常切换参数还是老老实实写launch.json或者用任务更靠谱。3. 输出乱码、输入卡死、路径跑飞一次完整的排查链路3.1 现象一中文输出变成一堆问号或者方块这是 Code Runner 最常见的问题没有之一。但不同原因造成的乱码处理方式完全不一样所以第一步是判断乱码发生在哪一层。最简单的判断方法是在程序里直接输出一句中文字面量。如果 OUTPUT 面板里正常显示那说明程序内部的编码没问题问题出在程序输出到面板这一段如果 OUTPUT 面板里就已经是方块那问题在源文件编码或者编译环节。先说 OUTPUT 面板这一层。在 Windows 上系统的默认代码页通常是 GBK而 VS Code 和它调起的子进程默认按 UTF-8 处理文本。两套编码一交叉中文就成了乱码。最直接的办法是让程序自己按 UTF-8 输出。以 Python 为例可以在用户环境变量里加一条PYTHONIOENCODINGutf-8这样所有 Python 进程的标准输入输出都用 UTF-8不依赖系统的代码页设置。这个办法覆盖面最广配一次就一劳永逸。如果你选择用集成终端来跑那还要再考虑终端自己的编码。Windows 的 PowerShell 默认可能是 GBK 代码页需要在 PowerShell 的配置文件里加上[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8把这两行写进 PowerShell 的 profile 文件用$PROFILE可以看到路径重启终端后生效。之后无论是 Code Runner 还是你手动执行命令中文都能正常显示。再说源文件这一层。VS Code 右下角的状态栏会显示当前文件的编码如果打开文件时看到的是 GBK 而不是 UTF-8那么源文件里的中文字节和编辑器当前使用的编码就对不上了。这种情况用通过编码重新打开和通过编码保存两个操作就能解决统一成 UTF-8 之后再重新编译。最后说编译环节。C 其实对中文字符串本身没有编码概念它只会把字节原样存进可执行文件Java 和 C# 就不一样编译器需要知道源文件的编码看错了就会直接报错或者产出乱码。这就是为什么前面 Java 那条命令必须带-encoding UTF-8。3.2 现象二光标一直闪scanf/cin/input()收不到任何输入这个现象我遇到太多次了第一次遇到时排查了半个小时最后才发现根本不是代码的问题。原因就是前面提到的默认的 OUTPUT 面板没有标准输入。判断方法很快——运行一个只有一行print(start)后面跟一个input()的脚本。如果你看到 start 打印出来了然后程序就一直停在那里没有任何报错那就是这个问题。解决方案只有一个把code-runner.runInTerminal改成true。改成终端模式之后还有两个小细节要注意。一是 Code Runner 在终端里执行命令时会复用同一个终端窗口所以你上一次运行残留的输出会一直在上面输入的时候容易和自己的输出混在一起看不清楚哪个是程序要求的输入。二是如果你在终端模式下用code-runner.clearPreviousOutput它清屏的行为是发送清屏控制字符在 Windows 上是cls有时候会和程序的输出挤在同一行看起来有点乱但功能没问题。还有一个更隐蔽的情况程序确实在终端模式下运行了但输入的时候按回车没反应多按几次反而攒了一堆。这通常是终端的前端输出把光标位置搞乱了按一下回车或者重新运行一次就能恢复。如果频繁出现把这个终端窗口关掉重新运行让 Code Runner 新开一个干净的终端。3.3 现象三读文件报 FileNotFoundError文件明明就在旁边这是code-runner.fileDirectoryAsCwd这个设置造成的前面提过这里展开讲一下排查过程。第一次遇到的时候我完全想不通open(data.txt)里的 data.txt 和 .py 文件在同一个目录为什么找不到后来在代码里加了一行print(os.getcwd())输出的路径是工作区根目录而不是源文件目录。真相就在这里——Python 解释器接收的是文件的绝对路径所以它知道去哪找 .py 文件但程序运行时的当前工作目录是另一个概念由启动进程时所在的目录决定。Code Runner 默认把工作目录设成工作区根目录所以open(data.txt)这个相对路径是相对于根目录解析的。知道了原因解决方式就有三种按场景选把code-runner.fileDirectoryAsCwd设为true工作目录跟着文件走。这是最省事的做法适合绝大多数单文件脚本。在代码里用__file__推导路径比如os.path.join(os.path.dirname(os.path.abspath(__file__)), data.txt)。这个做法不依赖任何编辑器设置把脚本拷到别的机器上照样能跑是我更推荐的长期方案。用绝对路径。临时调试可以写到项目里就不合适了。C 里也有完全对等的问题ifstream fin(data.txt)也一样受工作目录影响。而且 C 还有个额外的坑就是前面提到的那条默认命令里已经包含cd $dir也就是说 C 的运行工作目录其实被命令本身切换到了源文件目录和 Python 的默认行为不一致。同一个项目里两种语言表现不同很容易让人产生我记错了的错觉。所以我在配置里干脆把fileDirectoryAsCwd统一设成true让所有语言的行为一致。3.4 现象四写了个死循环怎么都停不下来算法题里写个while(true)调试太正常了。但如果这发生在 OUTPUT 面板模式下情况会有点麻烦——面板里的输出会疯狂滚动刷屏而且面板本身没有暂停按钮。Code Runner 提供了一个停止命令code-runner.stop默认快捷键是 CtrlAltM。在 OUTPUT 模式下它基本能正常结束进程。但如果输出太快面板刷得你根本看不清可以先去 VS Code 的命令面板里执行一次停止 Code Run然后再看输出。终端模式下会稍微麻烦一点。Code Runner 在集成终端里启动的是一个子进程停止命令依赖 VS Code 的终端进程管理在部分平台上并不能可靠地结束掉那个子进程。最可靠的办法是点一下终端区域然后按 CtrlC 手动中断。Windows 上如果 CtrlC 也不管用可以点击终端面板右上角的垃圾桶图标把整个终端关掉Code Runner 下次运行会重新开一个。还有个预防性的做法写循环调试的时候在循环体里加一句打印计数器的语句并且设一个上限比如到一千次就 break。这样即使忘了停也就是一瞬间的事不会把面板刷到卡顿。这个习惯看起来笨但它能省掉不少等程序停的时间。4. 编译型语言的专属麻烦4.1 C 默认命令的适用范围那条默认的 C 命令我前面拆解过它只适用于一个 .cpp 文件、用标准库、没有额外依赖这种情况。一旦超出这个范围你要么改命令要么换工具。常见的超出范围的情况有这么几种。用了相对路径引用的头文件——默认命令没有加-I参数编译器找不到自定义头文件。用了第三方库——需要额外的-I和-L参数。项目分成多个源文件——默认命令只编译当前文件链接时会报未定义的引用。这些情况并不是 Code Runner 的问题而是它本来就不负责多文件工程。我的判断标准很简单如果这个程序需要两个以上源文件才能跑起来就不该用 Code Runner应该去写tasks.json或者直接用构建工具。硬要改 executorMap 也能跑但配置会越滚越大最后变成一个没人看得懂的字符串得不偿失。4.2 多文件编译的三种可行做法如果你确实想在 Code Runner 里跑多文件的小程序比如做数据结构作业把实现拆成了 .h 和 .cpp有三条路可走。第一条是把命令改成编译整个目录下的所有源文件cpp: cd $dir g -stdc17 $dir/*.cpp -o \$fileNameWithoutExt\ $dir$fileNameWithoutExt注意这条命令里$dir/*.cpp是由 shell 展开的在 Windows 上如果用 PowerShell 可能有兼容性问题用 Git Bash 或者 cmd 更稳。另外如果目录里有多个 main 函数比如有好几个独立的练习题这条命令会直接报重复定义的错误。第二条是显式列出要编译的文件cpp: cd $dir g -stdc17 main.cpp utils.cpp -o main $dirmain这条最稳缺点是每加一个文件都要改一次配置。第三条是改用任务。在项目下建一个.vscode/tasks.json定义一个编译任务然后用运行任务CtrlShiftB触发。这条路的配置更规范也能和调试打通代价是要学一下 tasks.json 的写法。我的建议是两个文件的练习用第二种三个以上文件的就转去用任务或者 CMake。4.3 Java 的类名必须和文件名一致Java 这条链路上最容易踩的坑是文件名和类名不一致。Java 规定 public 类名必须和文件名完全相同包括大小写。而 Code Runner 执行的是cd $dir javac $fileName java $fileNameWithoutExt最后那个java $fileNameWithoutExt用的是文件名去调用类所以如果你把文件命名为main.java而里面写的是public class Solution编译能过但运行时会报找不到或无法加载主类。这看起来很蠢但在做题的时候特别容易出现因为大家习惯把文件命名成 Solution 或者 Main随手又把文件另存成别的名字。另外一个和 Java 相关的坑是包声明。如果文件里有package com.example;这行那么编译产物的目录结构必须匹配包名否则运行时会报找不到主类。Code Runner 默认的命令不带-d参数产物就直接落在源文件旁边包声明和目录结构自然对不上。要么把 package 那行删掉做题时通常也不需要要么改用 Maven/Gradle 跑。4.4 路径里的中文和空格引发的连锁反应这一条我专门拿出来讲因为它的表现非常具有迷惑性——报错信息往往和真正的原因完全不相干。如果你的项目路径是D:\我的代码\算法练习\那么$dir展开后包含中文。对大多数场景这没问题但对某些工具链就是灭顶之灾。比如某些版本的 GCC 在处理含中文的路径时会因为编码转换失败导致输出文件写不出来报出的错误是无法创建文件或者干脆是一串乱码。又比如命令行解释器在处理含空格路径时会把路径切开编译器收到两个参数报错说没有输入文件。处理方式分两步。第一步把所有展开路径的地方都加上双引号比如g $fullFileName -o $dirWithoutTrailingSlash\$fileNameWithoutExt先解决空格问题。第二步如果确认是中文路径导致的最彻底的办法是把代码仓库放在一个纯英文、无空格的路径下比如D:\code\或者用户目录下的~/dev/。这听起来像是妥协但实际开发中确实有相当一部分工具链对非 ASCII 路径支持不好把仓库放在英文路径下能避免一大堆说不清的怪问题。顺带提醒一下路径长度在 Windows 上也有上限传统上限是 260 个字符。如果你把项目放在层级很深的目录里再加上 Code Runner 展开出来的$dir前缀很容易触顶报出的错误可能是文件名或扩展名太长。挪到浅一点的目录就能解决。5. 什么时候该把 Code Runner 关掉5.1 需要断点调试的时候Code Runner 和调试是两条完全不同的路。它执行的是命令行里的编译运行没有调试器介入所以你没法设断点、看调用栈、单步执行、查看变量。它给你的只有标准输出和退出码。需要这些能力的时候就老老实实用 VS Code 的内置调试功能。C/C 装好 C/C 扩展之后第一次按 F5 会引导你生成launch.jsonPython 装好 Python 扩展之后F5 就能直接进入调试。这些配置写起来比 Code Runner 麻烦但换来的是真正可交互的调试体验。我自己的习惯是两套并存写的时候用 Code Runner 快速验证输出逻辑不对了再切到调试器断点排查。它们不冲突因为 Code Runner 的配置在用户设置里调试配置在项目的.vscode/launch.json里互不干扰。5.2 需要传命令行参数的时候argc/argv、sys.argv、process.argv这类东西Code Runner 默认是传不进去的。它传给程序的就是文件路径本身没有额外的参数。如果是固定参数前面的executorMapByGlob或者直接改 executorMap 就能解决。但如果参数需要经常改或者需要根据输入数据文件切换那就别折腾了用launch.json的args字段更合适——它是个数组改起来直观还能保存多套配置用下拉框切换。5.3 虚拟环境与解释器切换这是 Code Runner 和 Python 用户之间最常见的摩擦。你明明在 VS Code 里选了 venv 里的解释器右下角显示得好好的但用 Code Runner 跑的时候社区包还是提示找不到。原因是 Code Runner 执行python这个命令时走的是系统 PATH 里那个全局解释器而不是你在 VS Code 里选的那个。解决方式是把命令里的python换成$pythonPathpython: $pythonPath -u $fullFileName$pythonPath会展开成当前选中的解释器的完整路径包括虚拟环境里的那一个。这个变量需要装 Python 扩展才有值装了就有效。替换之后虚拟环境的切换就自动跟着 VS Code 的解释器选择走了切一次环境运行的地方也跟着换。如果用的是 conda 环境同样的道理把python换成conda run -n 环境名 python也行不过conda run会带来一点启动开销每次运行多等一秒左右看你能不能接受。5.4 构建系统接管之后项目一旦引入 CMake、Maven、Cargo、npm scripts 这类构建工具Code Runner 就该退场了。原因很直接这些工具的配置里已经包含了编译参数、依赖路径、输出目录、多模块关系你不可能在一条 executorMap 字符串里复现它们复现了也维护不了。到了这个阶段正确的做法是用运行任务或者构建工具自己的命令。比如 CMake 项目配好tasks.json之后CtrlShiftB 就能触发构建再配合 launch.json 就能断点调试。Code Runner 留给那些一次性的、孤立的脚本文件用。6. 那些文档里没写的小细节6.1 快捷键与误触Code Runner 默认绑定了几个快捷键。运行整个文件是 CtrlAltN停止运行是 CtrlAltM。这两个组合键的选法有点讲究它们不会和 VS Code 内置的 F5开始调试、CtrlF5不调试运行冲突所以你可以三套都留着。但 CtrlAltN 有个实际使用中的问题在某些输入法状态下CtrlAlt 组合会被输入法截走导致快捷键失效。如果你发现按了没反应先切到英文输入法再试。另外某些笔记本的键盘布局下CtrlAltN 可能和系统的某个组合键冲突这种情况下可以到键盘快捷方式里搜code-runner.run换一个自己顺手的组合。还有个容易忽略的点如果编辑区里选中了文本而你之前把code-runner.ignoreSelection关掉过运行的就只是选中那一段。表现是程序只输出了一半结果或者报了个语法错误但我明明看整个文件是对的。检查一下这个设置能省下不少迷惑时间。6.2 输出面板的清屏与历史code-runner.clearPreviousOutput默认是true意思是每次运行前清空上一次的输出。这个设置在我看来是必须保持开启的否则跑十几次之后面板里全是历史输出你根本分不清哪一段是这一次的结果。特别是跑了死循环之后如果不自动清屏下次运行还得手动清一次。但要注意OUTPUT 面板本身在所有扩展之间是共享的一个区域。如果你同时装了其他也往 OUTPUT 面板写日志的扩展切换下拉框的时候可能会看到别的扩展的输出混在里面。这时候别慌在右上角的下拉框里切回 Code Runner 就行。还有一个细节OUTPUT 面板里的内容是可以全选复制的鼠标选中后 CtrlC。有时候跑出来一大段结果想拿去比对直接在面板里复制比去终端里翻要方便。终端里的复制有额外的格式处理可能会带上奇怪的换行反而不好用。6.3 与保存、格式化的联动code-runner.saveFileBeforeRun和code-runner.saveAllFilesBeforeRun这两个设置经常被搞混。前者只保存当前正在编辑的那个文件后者会保存工作区里所有被修改过的文件。如果你在一个多文件的小脚本里改了辅助文件但只在主文件上按了运行那么带All的那个设置才有用。默认情况下前者是true、后者是false我建议保持这个组合因为有时候你并不希望一个临时改了一半的文件被顺手保存进去。另外如果你开了保存时自动格式化那么运行前保存这个动作会顺带触发格式化。绝大多数情况下这是好事它能保证你跑的是格式化之后的代码。但如果你用了某种格式化规则和实际运行不一致的插件比如它对某个语法支持不好格式化之后反而改坏了代码那就会造成运行结果和我写的代码对不上的诡异现象。遇到这种情况先临时关掉格式化看看问题是不是还在这能帮你快速定位到底是代码问题还是工具链问题。最后分享一个我自己一直在用的小技巧给 Code Runner 的运行命令统一加上计时。C 里可以用time命令包一层macOS/Linux或者 PowerShell 的Measure-CommandWindowsPython 则在脚本开头记一个时间戳、结尾算差值。这样每次运行完除了结果还能顺手看到耗时。做算法题的时候这个数字能直接告诉你有没有超时风险比事后去评测平台上试要主动得多。cpp: cd $dir g -stdc17 -O2 \$fileName\ -o \$fileNameWithoutExt\ time $dir$fileNameWithoutExt-O2这个优化参数顺便提一句调试阶段不建议加因为它会改变某些未定义行为的表现让 bug 更难复现准备测性能的时候再加测完记得去掉。