操作:把 images/00-cover.png 拖到下面这行位置,然后删掉本注释与本行文章目录一、先说结论:90% 的人配不好,是因为搞错了一件事VSCode 本身不是 IDE,它是一个带插件的编辑器。二、第一步:编译器到底选哪个?(这一步选错,后面全是坑)三、第二步:装 MinGW-w64 并配好 PATH3.1 去哪下?别乱下3.2 配 PATH(最关键的一步)3.3 验收:这一步必须过四、第三步:装 VSCode 扩展(只装必要的)五、第四步:四个配置文件,各管一件事全文最值钱的一句话六、tasks.json:编译是怎么发生的(逐行讲透)逐行解释(只讲你会用到的)关于路径写法:为什么用 / 而不是 \验证编译七、c_cpp_properties.json:只负责编辑器的体验八、launch.json:调试是怎么发生的断点变灰的四个原因(按出现概率排序)关于 externalConsole九、settings.json:顺手把编码和终端理顺十、中文输出乱码:一张图讲透,一次解决原理:一句话版本两种解法(任选其一,千万别混用)十一、多文件编译怎么办?方式一:把源文件都列进 args(适合 2~4 个文件)方式二:用通配符(MinGW 下可用,但有前提)什么时候该上 CMake?十二、完整实战:从零跑通一个带断点的程序十三、12 个高频报错速查表(建议截图保存)十四、配置成功的 7 个验收标准十五、几个被问爆的问题(可能和你想的不一样)十六、总结写在最后:想听听你的情况环境说明:Windows 10 / 11 · VSCode 1.9x · MinGW-w64(GCC 12 及以上均可)· GDB 12 及以上。发布前请把这里改成你自己机器上的真实版本(终端执行g --version和gdb --version即可看到)。本文约定:全文以编译器装在D:\w64devkit为例,请你把它替换成自己的实际路径。路径不同不会导致报错,路径写错才会。阅读建议:配置卡住时,直接跳到第 13 节的报错速查表对号入座;想彻底搞懂,按顺序读。一、先说结论:90% 的人配不好,是因为搞错了一件事先看三个我见过太多次的翻车现场,如果你中了任意一条,这篇就是写给你的:翻车现场 A:跟着某篇 2019 年的教程下了个 MinGW,解压、配 PATH、装插件,一气呵成。然后新建main.cpp,按 F5 —— 弹出一个launch.json让你选环境,选完还是跑不起来。翻车现场 B:代码能跑了,但终端输出浣犲ソ。于是开始百度VSCode 中文乱码,改一句chcp 65001,换个字体,折腾两小时,时好时坏。翻车现场 C:行号左边点了个红点,红点永远是灰色的空心圆。F5 之后程序一闪而过,断点根本没停。这三个问题的根源不是 VSCode 难用,而是没人告诉你一个前提:VSCode 本身不是 IDE,它是一个带插件的编辑器。它自己不编译、不调试。它做的事情只有一件:按照你给的配置文件,替你调用外部程序。编译 调用g.exe调试 调用gdb.exe补全和红线 插件自己猜的,和编译毫无关系所以配环境的本质,是告诉 VSCode 这两个程序在哪里、以及怎么调用它们。想通这一点,后面所有 json 都不再是天书。本文的完整路线就是上图这 5 步。每一步我都给了验收标准,你可以随时回头检查自己走到哪了。二、第一步:编译器到底选哪个?(这一步选错,后面全是坑)打开搜索引擎搜VSCode 配置 C,你会同时看到 MinGW、MSVC、WSL 三种方案,然后新人就开始纠结。先给结论,别纠结:你的目标选它理由学语法、刷算法题、写课程设计MinGW-w64(GCC)产物是单个 exe,双击就跑,没有额外依赖要投 Linux 后端 / 后端开发岗WSL2(Ubuntu)和面试、部署环境完全一致,不用后期迁移做 Windows 桌面程序、游戏、大工程MSVCWindows 原生兼容性最好,调试体验最顺本文主推 MinGW-w64,原因很简单:它是三者里唯一解压就能用、出错信息最直白的。跑通了 GCC 这一套,以后再迁 WSL 或 MSVC,配置文件改两行就行。三、第二步:装 MinGW-w64 并配好 PATH3.1 去哪下?别乱下网上搜MinGW-w64 下载,前几个结果里有一堆个人打包站,版本老旧、来源不明,还经常夹带东西。推荐两条干净路线:路线一(新手首选,推荐):w64devkit到 GitHub 搜w64devkit,下载w64devkit-x.x.x.zip(约 80 MB)解压到D:\w64devkit(路径不要有中文和空格)自带的bin目录里一次配齐g.exe、gcc.exe、gdb.exe、make.exe优点:解压即用,不用装任何安装器,自带 gdb,不会出现装了编译器却找不到 gdb的经典问题。路线二(要长期用、需要包管理):MSYS2# 1. 官网下载 msys2-x86_64-xxxx.exe 并安装到 C:\msys64# 2. 打开 MSYS2 UCRT64 终端,先更新核心pacman-Syu# 3. 装工具链(约 200 MB,耐心等)pacman-S--neededbase-devel mingw-w64-ucrt-x86_64-toolchain# 4. 单独装 gdb(toolchain 里不一定包含)pacman-Smingw-w64-ucrt-x86_64-gdb装完的bin目录在C:\msys64\ucrt64\bin。3.2 配 PATH(最关键的一步)不管你走哪条路线,都要做这件事。没配 PATH,后面必报「无法将 g 项识别为 cmdlet」。按Win R,输入sysdm.cpl,回车「高级」选项卡 → 「环境变量」在**下半部分的「系统变量」**里找到Path,双击点「新建」,粘贴你的 bin 目录,例如D:\w64devkit\bin一路点「确定」(很多人只点一次就关了,等于没保存)彻底关闭 VSCode 和所有终端窗口,重新打开—— PATH 是进程启动时读取的,不重启不生效3.3 验收:这一步必须过新开一个命令提示符或 PowerShell,依次输入:g--version gdb--version两条都能打印出版本号(类似g (GCC) 14.2.0),才算成功。如果提示「无法将g项识别为 cmdlet 的名称」,不要往下走。回到 3.2,检查路径是否写错、是否点了三次确定、是否重启了终端。这一步不通过,后面 100% 会失败。四、第三步:装 VSCode 扩展(只装必要的)打开扩展面板(CtrlShiftX),搜C/C,认准发布者是Microsoft,安装。必装:扩展作用C/C(Microsoft)提供补全、跳转、红线、调试支持,是核心可选:扩展建议Chinese (Simplified) Language Pack中文界面,看个人习惯Code Runner键运行单文件,适合刷题。但它不参与调试Better C Syntax语法高亮更准确,装了不亏clangd补全更快,但必须卸载/禁用 Microsoft C/C 的 IntelliSense,否则两个引擎打架关于 clangd 的争议:clangd 的补全质量和速度确实比微软自带的好,但它配置门槛更高,而且和cpptools冲突时会出现红线乱跳。我的建议是:新手先别碰。等你对这套配置彻底熟悉了再换。装完扩展,右下角可能会弹提示检测到 #include 错误,请更新 includePath。先别管它—— 下一节解释为什么。五、第四步:四个配置文件,各管一件事现在到了最核心的部分。在项目根目录新建一个.vscode文件夹,里面会有 4 个可能的 json。新人最大的困惑是:到底哪个文件管什么?先看这张图,记住它,后面就顺了。文件管什么出问题时的症状c_cpp_properties.json只影响编辑器:补全、跳转、红线有红线,但程序能正常跑tasks.json管编译:怎么调用g.exe编译报错、找不到 glaunch.json管调试:怎么调用gdb.exe断点灰色、F5 没反应settings.json编辑器全局行为:编码、格式化、终端中文乱码、Tab 缩进全文最值钱的一句话编辑器里的红线来自c_cpp_properties.json,能不能编译成功只取决于tasks.json。所以「有红线但能跑」和「没红线但编译报错」都是完全正常的现象 —— 它们分别是两个文件的问题,别混在一起查。这句话能帮你省下大量时间,因为网上大部分VSCode C 报错的答案,根本没区分这两类问题。六、tasks.json:编译是怎么发生的(逐行讲透)先看一张图,理解按下CtrlShiftB之后到底发生了什么。核心认知:tasks.json里的args数组,就是你在终端手敲的命令。没有任何魔法。下面这份配置可以直接复制(记得把两处D:/w64devkit/bin/g.exe换成你的路径):{version:2.0.0,tasks:[{type:cppbuild,label:C/C: g.exe 生成活动文件,command:D:/w64devkit/bin/g.exe,args:[-fdiagnostics-coloralways,-g,-fexec-charsetGBK,${file},-o,${fileDirname}\\${fileBasenameNoExtension}.exe],options:{cwd:${fileDirname}},problemMatcher:[$gcc],group:{kind:build,isDefault:true},detail:编译器: D:/w64devkit/bin/g.exe}]}逐行解释(只讲你会用到的)字段含义注意事项label任务名,就是个名字后面launch.json要用它,必须逐字符一致command要调用的程序写绝对路径最稳;写g也行,但依赖 PATH 生效-fdiagnostics-coloralways让报错信息带颜色纯好看,可以删-g生成调试信息删了它,断点永远是灰色。这条是重中之重-fexec-charsetGBK让输出的中文用 GBK 编码解决中文乱码,原理见第 8 节${file}当前打开的源文件VSCode 内置变量-o指定输出文件名${fileDirname}\\${fileBasenameNoExtension}.exe输出到源文件旁边,同名 exe${fileBasenameNoExtension}是不含后缀的文件名group: { kind: build, isDefault: true }把它设为默认生成任务这样CtrlShiftB才会直接跑它关于路径写法:为什么用/而不是\两种写法 Windows 都认。但\在 JSON 里是转义字符:写D:\w64devkit\bin时,\b会被解析成退格符,路径直接变形,然后报一个让你完全摸不着头脑的错。所以要么用正斜杠D:/w64devkit/bin/g.exe,要么写双反斜杠D:\\w64devkit\\bin\\g.exe。我全文统一用正斜杠,省事。验证编译打开一个main.cpp,按CtrlShiftB,选择刚配好的任务。终端出现类似下面的输出就成功了:正在启动生成... D:/w64devkit/bin/g.exe -fdiagnostics-coloralways -g -fexec-charsetGBK main.cpp -o main.exe 生成成功,用时 0.5 秒此时源文件旁边应该出现了main.exe。七、c_cpp_properties.json:只负责编辑器的体验这个文件不参与编译,它只告诉 IntelliSense(补全引擎)去哪里找头文件。{version:4,configurations:[{name:Win32,includePath:[${workspaceFolder}/**],defines:[_DEBUG,UNICODE,_UNICODE],compilerPath:D:/w64devkit/bin/g.exe,cStandard:c17,cppStandard:c17,intelliSenseMode:windows-gcc-x64}]}关键字段只有两个:compilerPath:最重要。指向你的g.exe。插件会自动从 GCC 里读取所有内置的头文件路径,所以通常你不需要手写includePath。intelliSenseMode:GCC 64 位 Windows 就填windows-gcc-x64。填错了会补全异常。重要提醒:如果你出现「无法打开源文件iostream」这类红线,但CtrlShiftB能正常编译通过 —— 那这就是本文件的问题,去改compilerPath。反过来,如果编译时报fatal error: iostream: No such file or directory,那是tasks.json或编译器安装的问题,改这个文件没用。八、launch.json:调试是怎么发生的调试失败的 90% 原因,都在这条链路上。先看图:配置如下(把路径换成你的):{version:0.2.0,configurations:[{name:C/C: g.exe 调试活动文件,type:cppdbg,request:launch,program:${fileDirname}\\${fileBasenameNoExtension}.exe,args:[],stopAtEntry:false,cwd:${fileDirname},environment:[],externalConsole:false,MIMode:gdb,miDebuggerPath:D:/w64devkit/bin/gdb.exe,setupCommands:[{description:为 gdb 启用整齐打印,text:-enable-pretty-printing,ignoreFailures:true},{description:将反汇编风格设置为 Intel,text:-gdb-set disassembly-flavor intel,ignoreFailures:true}],preLaunchTask:C/C: g.exe 生成活动文件}]}三个必须一致的地方,对不上就调试不了:MIMode: gdb—— 用 MinGW 就填gdb,MSVC 才填cppvsdbgmiDebuggerPath——必须真实存在。报spawn gdb ENOENT就是这里错了,或者你的 MinGW 里根本没有 gdbpreLaunchTask——必须和tasks.json里的label一字不差,包括空格关于preLaunchTask,我再强调一次,因为这是最高频的坑:tasks.json里写的是C/C: g.exe 生成活动文件(注意C/C后面的冒号加空格)。你在launch.json里写成C/C:g.exe 生成活动文件或者换了半角/全角符号,F5 就会报「preLaunchTask 已终止」或者断点是灰的。最省事的做法:直接复制粘贴,不要手打。断点变灰的四个原因(按出现概率排序)tasks.json的args里没有-g→ 补上,重新生成一次preLaunchTask与label不一致→ 逐字符核对program指向了旧的 exe→ 删掉旧 exe 重新编译MinGW 里根本没有gdb.exe→ 换 w64devkit,或用 MSYS2 装 gdb关于externalConsolefalse(推荐):程序在 VSCode 的集成终端里跑,输出不会一闪而过,可以直接看true:弹出一个独立黑窗口,程序结束就关闭。新人常以为程序没运行,其实是闪退了九、settings.json:顺手把编码和终端理顺这个文件放.vscode/settings.json(只对当前项目生效),或者用全局设置。{files.encoding:utf8,files.autoGuessEncoding:true,editor.tabSize:4,editor.insertSpaces:true,C_Cpp.default.compilerPath:D:/w64devkit/bin/g.exe,code-runner.runInTerminal:true,code-runner.executorMap:{cpp:cd $dir g -fexec-charsetGBK -g $fileName -o $fileNameWithoutExt $dir$fileNameWithoutExt},code-runner.saveFileBeforeRun:true}files.encoding设为utf8,是为了保证你的源码永远以 UTF-8 保存。这一条是第 10 节解决乱码的前提。十、中文输出乱码:一张图讲透,一次解决这是评论区问得最多的问题,而且网上的答案大多是抄一段能用的,没人讲原理。所以我单独用一节说清。原理:一句话版本源文件用什么编码写,输出就得到什么编码的字节;但终端用什么编码读,是由 Windows 代码页决定的。两边不一致,就乱码。具体链路是:你的源码以UTF-8保存,你好在文件里是 6 个字节E4 BD A0 E5 A5 BDGCC 编译时原样保留这串字节程序运行时把这 6 个字节直接写给控制台简体中文 Windows 控制台默认代码页是936(GBK),它按 GBK 去解释 UTF-8 的字节 → 变成浣犲ソ顺带一提:你可能见过更离谱的锟斤拷。那是 UTF-8 字节被错误解码后,又用 UTF-8 编码了一次的产物。它的出现意味着中间经过了两轮错误转换。两种解法(任选其一,千万别混用)方案 A:源码保持 UTF-8 编译加参数(最省事,推荐)在tasks.json的args里加一行:-fexec-charsetGBK含义是:让 GCC 把字符串常量转成 GBK 字节输出。这样写出去的字节和控制台读的编码就一致了。✅ 源文件继续用 UTF-8,和 Git、跨平台协作都一致✅ 一行搞定,不用改代码⚠️ Linux / macOS 不需要这个参数,跨平台项目要分开维护配置方案 B:让控制台改成 UTF-8(更正确,跨平台一致)保持源码 UTF-8,去掉-fexec-charsetGBK,然后在运行程序前把控制台切到 UTF-8:chcp 65001.\main.exe✅ 真正跨平台一致,Linux 上也是这套⚠️ 每次开新终端都要执行一次;某些老程序在 65001 下可能有兼容问题⚠️ 别忘了这一步,否则又会乱码❌ 千万别做的事:把源文件另存为 GB2312/GBK。这在你自己机器上确实能不乱码,但代价是:Git 里中文 diff 显示异常、别人 clone 下来编译报错、换台电脑又得重存。这是技术债,不是解决方案。十一、多文件编译怎么办?到这一步,你配的都是编译当前单个文件。一旦项目有多个.cpp,就要处理这个问题。方式一:把源文件都列进 args(适合 2~4 个文件)args:[-fdiagnostics-coloralways,-g,-fexec-charsetGBK,${fileDirname}\\main.cpp,${fileDirname}\\student.cpp,${fileDirname}\\utils.cpp,-o,${fileDirname}\\${fileBasenameNoExtension}.exe]缺点很明显:每加一个文件就要改一次 json。文件超过 5 个就别这么干了。方式二:用通配符(MinGW 下可用,但有前提)${fileDirname}\\*.cppMinGW-w64 的g内置了通配符展开,所以这条在 Windows MinGW 下通常能用。但依赖运行时的 glob 支持,不是所有平台都可靠。如果你用的是 MSVC 或 WSL,这条很可能失效,请老实列出文件名,或者直接上 CMake。什么时候该上 CMake?我的分界线是5 个源文件:≤ 5 个文件:继续手写 json。零依赖、看得见每一步在干什么,出错了也好排查 5 个文件,或者要引第三方库:换 CMakeCMake 的最小配置长这样:cmake_minimum_required(VERSION 3.20) project(MyProject CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 把 src 下所有 cpp 都编进来(新增文件自动纳入,不用改配置) file(GLOB SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp) add_executable(MyProject ${SOURCES})然后在 VSCode 里装CMake Tools扩展,选好工具链,按 F5 就能直接调试 ——调试配置由扩展自动生成,你再也不用碰launch.json。这就是它最大的价值。关于要不要一上来就用 CMake:我的观点很明确 ——不要。CMake 多了一层构建系统,出错时你不会知道问题出在 CMake、编译器还是 VSCode。先用第 6 节的手写 json 跑通全部流程,再迁移。十二、完整实战:从零跑通一个带断点的程序把前面的东西串起来。新建main.cpp:#includeiostream#includevector#includestringstructStudent{std::string name;intscore;};intmain(){std::vectorStudentstudents{{张三,92},{李四,78},{王五,85}};inttotal0;for(constautos:students){std::couts.name 的分数是 s.scorestd::endl;totals.score;// ← 在这一行点一个红点}doubleaveragestatic_castdouble(total)/students.size();std::cout平均分:averagestd::endl;return0;}操作步骤:第 23 行(total s.score;)的行号左侧空白处点一下 → 出现红色实心圆按F5→ 选择 “C/C: g.exe 调试活动文件”程序会先自动编译,然后停在断点处验证成功的标志:断点是红色实心圆(灰色空心 没生效)左侧「变量」面板里能看到students、total、s的值顶部出现调试工具栏,可以单步(F10)、步入(F11)、继续(F5)调试小技巧:在「监视」面板里输入students[0],或者把鼠标悬停在变量上,就能看到vector里每一个元素 —— 前提是setupCommands里的-enable-pretty-printing生效了。没有它,你只能看到一堆看不懂的内存地址。十三、12 个高频报错速查表(建议截图保存)图片版方便截图,文字版方便复制搜索:#报错原文原因解决1无法将g项识别为 cmdlet 的名称PATH 没配或没重启 VSCode把 bin 目录加进系统 PATH,彻底重启 VSCode2undefined reference to xxx函数声明了没实现,或多文件没一起编译把源文件都写进 args,或改用 CMake3collect2.exe: error: ld returned 1 exit status最常见是main拼成了mian看上面一行的真实提示,那才是根因4error: cout was not declared in this scope忘了#include iostream或std::补头文件,或用using namespace std;5fatal error: iostream: No such file or directorycompilerPath 指错,或 MinGW 装得不完整指向...\bin\g.exe,推荐换 w64devkit6preLaunchTask 已终止,退出代码为 1编译失败,调试因此没启动先单独CtrlShiftB把编译错误解决掉7spawn gdb ENOENTMinGW 里没有gdb.exe换 w64devkit,或改miDebuggerPath8断点是灰色空心圆,未加载符号编译缺-g,或preLaunchTask不一致args 加-g;label 与 preLaunchTask 完全一致9中文乱码浣犲ソ/锟斤拷源码 UTF-8 与控制台 GBK 不一致args 加-fexec-charsetGBK10无法打开源文件stdio.h(红线)IntelliSense 找不到头文件(≠ 编译失败)改c_cpp_properties.json的compilerPath11code命令不可用 / 右键没有在终端中打开装 VSCode 时没勾选添加到 PATH重装并勾选,或手动把 VSCode 的 bin 加入 PATH12json 里注释报错 / 不允许尾随逗号VSCode 的 json 是严格模式删掉注释和多余逗号看图技巧:第 3 条和第 6 条属于假报错。ld returned 1 exit status和preLaunchTask 已终止永远不是根因,往上翻看真正的错误行。十四、配置成功的 7 个验收标准别凭感觉判断好像配好了,对着这张图逐条自测:全部打勾,你的环境就是真的配好了:终端执行g --version,能打印版本号执行gdb --version,能打印版本号F1搜C/C: Edit Configurations能打开 jsonCtrlShiftB后终端提示生成成功源文件旁出现main.exe,双击能运行F5后断点由灰色变红色实心终端输出中文不是乱码十五、几个被问爆的问题(可能和你想的不一样)Q1:为什么你的路径用正斜杠D:/,我用反斜杠行不行?行,但必须写双反斜杠D:\\w64devkit\\bin\\g.exe。JSON 里单反斜杠是转义字符,\m、\b会被解析成别的东西,然后报一个让你完全摸不着头脑的错。Q2:能不能不写绝对路径,直接写g?可以,前提是 PATH 真的生效了,而且必须重启过 VSCode。写绝对路径的好处是:换机器、改 PATH 都不会影响这个项目。我推荐绝对路径。Q3:一定要用 Code Runner 吗?不需要,而且我不太推荐新手依赖它。它本质就是帮你敲一行命令,但它的运行结果不经过launch.json,所以你没法断点调试、看不到符号。我见过不少人装了 Code Runner 之后,以为自己环境配好了,结果一调试就懵 —— 因为他压根没配tasks.json。Code Runner 适合刷算法题,不适合学调试。Q4:VSCode 一直提示检测到 #include 错误,是不是环境没配好?不一定。这是 IntelliSense 的提示,不是编译器说的。只要CtrlShiftB能编译通过,程序能跑,这个提示可以直接无视,或者按第 7 节改compilerPath消除它。Q5:程序运行完窗口一闪就没了?两个原因:一是externalConsole设成了true;二是你没在main的return前加暂停。把externalConsole改成false,输出就会留在集成终端里。Q6:Mac / Linux 上怎么配?基本一样,区别在:编译器路径不同(用which g查)、miDebuggerPath用which gdb、不需要-fexec-charsetGBK(它们默认就是 UTF-8)。intelliSenseMode改成macos-clang-arm64或linux-gcc-x64。Q7:为什么教程里都在教 MinGW-w64,你却推荐 w64devkit?因为网上那些MinGW-w64 下载链接大多是个人打包的旧版本,有的连gdb.exe都不带 —— 这正是「装好了编译器却调试不了」这个经典问题的来源。w64devkit 是官方维护的干净打包,解压即用,而且自带 gdb。十六、总结回头看,整件事其实只有三句话:VSCode 不编译也不调试,它只是按配置去调用g.exe和gdb.exec_cpp_properties.json管体验(红线),tasks.json管编译,launch.json管调试—— 出问题先分清是哪一类大部分玄学报错都有确定原因:断点灰 少了-g;乱码 编码不一致;preLaunchTask 已终止 名字对不上配置一次,能用很久。建议把这篇收藏,下次换电脑或者帮同学配环境时直接用。写在最后:想听听你的情况这篇文章里的 12 个报错,都是我在评论区和身边同学那里真实收集到的。但肯定还有我没覆盖到的坑。所以想请你帮个忙,在评论区留下:你卡在第几步?把完整报错原文(包括最后一行)贴出来,我会逐条回复,并把新的坑补进上面那张速查表 —— 你踩的坑,也是下一个人的坑。你用的是哪个工具链?MinGW-w64 / MSVC / WSL2。我很好奇大家的实际选择,这个数据也能帮我决定下一篇写什么。有争议的点欢迎来辩:比如你觉得 Code Runner 到底该不该用?一上来就上 CMake 是好习惯还是过度设计?评论区见。如果这篇帮你省下了折腾环境的两三个小时,欢迎点个赞让更多刚入门的人看到 —— 环境配置是每个 C/C 学习者的第一道坎,而它本不该这么难。下一篇预告:《launch.json高级玩法:GDB 条件断点、内存监视与多线程调试》—— 想看的同学评论区扣个 1。标签建议:VSCodeCC语言开发工具环境配置gccgdb调试技巧34c6d74a95a0a76868e2760489.png#pic_center) vscode配置c/c++环境
操作:把 images/00-cover.png 拖到下面这行位置,然后删掉本注释与本行文章目录一、先说结论:90% 的人配不好,是因为搞错了一件事VSCode 本身不是 IDE,它是一个带插件的编辑器。二、第一步:编译器到底选哪个?(这一步选错,后面全是坑)三、第二步:装 MinGW-w64 并配好 PATH3.1 去哪下?别乱下3.2 配 PATH(最关键的一步)3.3 验收:这一步必须过四、第三步:装 VSCode 扩展(只装必要的)五、第四步:四个配置文件,各管一件事全文最值钱的一句话六、tasks.json:编译是怎么发生的(逐行讲透)逐行解释(只讲你会用到的)关于路径写法:为什么用 / 而不是 \验证编译七、c_cpp_properties.json:只负责编辑器的体验八、launch.json:调试是怎么发生的断点变灰的四个原因(按出现概率排序)关于 externalConsole九、settings.json:顺手把编码和终端理顺十、中文输出乱码:一张图讲透,一次解决原理:一句话版本两种解法(任选其一,千万别混用)十一、多文件编译怎么办?方式一:把源文件都列进 args(适合 2~4 个文件)方式二:用通配符(MinGW 下可用,但有前提)什么时候该上 CMake?十二、完整实战:从零跑通一个带断点的程序十三、12 个高频报错速查表(建议截图保存)十四、配置成功的 7 个验收标准十五、几个被问爆的问题(可能和你想的不一样)十六、总结写在最后:想听听你的情况环境说明:Windows 10 / 11 · VSCode 1.9x · MinGW-w64(GCC 12 及以上均可)· GDB 12 及以上。发布前请把这里改成你自己机器上的真实版本(终端执行g --version和gdb --version即可看到)。本文约定:全文以编译器装在D:\w64devkit为例,请你把它替换成自己的实际路径。路径不同不会导致报错,路径写错才会。阅读建议:配置卡住时,直接跳到第 13 节的报错速查表对号入座;想彻底搞懂,按顺序读。一、先说结论:90% 的人配不好,是因为搞错了一件事先看三个我见过太多次的翻车现场,如果你中了任意一条,这篇就是写给你的:翻车现场 A:跟着某篇 2019 年的教程下了个 MinGW,解压、配 PATH、装插件,一气呵成。然后新建main.cpp,按 F5 —— 弹出一个launch.json让你选环境,选完还是跑不起来。翻车现场 B:代码能跑了,但终端输出浣犲ソ。于是开始百度VSCode 中文乱码,改一句chcp 65001,换个字体,折腾两小时,时好时坏。翻车现场 C:行号左边点了个红点,红点永远是灰色的空心圆。F5 之后程序一闪而过,断点根本没停。这三个问题的根源不是 VSCode 难用,而是没人告诉你一个前提:VSCode 本身不是 IDE,它是一个带插件的编辑器。它自己不编译、不调试。它做的事情只有一件:按照你给的配置文件,替你调用外部程序。编译 调用g.exe调试 调用gdb.exe补全和红线 插件自己猜的,和编译毫无关系所以配环境的本质,是告诉 VSCode 这两个程序在哪里、以及怎么调用它们。想通这一点,后面所有 json 都不再是天书。本文的完整路线就是上图这 5 步。每一步我都给了验收标准,你可以随时回头检查自己走到哪了。二、第一步:编译器到底选哪个?(这一步选错,后面全是坑)打开搜索引擎搜VSCode 配置 C,你会同时看到 MinGW、MSVC、WSL 三种方案,然后新人就开始纠结。先给结论,别纠结:你的目标选它理由学语法、刷算法题、写课程设计MinGW-w64(GCC)产物是单个 exe,双击就跑,没有额外依赖要投 Linux 后端 / 后端开发岗WSL2(Ubuntu)和面试、部署环境完全一致,不用后期迁移做 Windows 桌面程序、游戏、大工程MSVCWindows 原生兼容性最好,调试体验最顺本文主推 MinGW-w64,原因很简单:它是三者里唯一解压就能用、出错信息最直白的。跑通了 GCC 这一套,以后再迁 WSL 或 MSVC,配置文件改两行就行。三、第二步:装 MinGW-w64 并配好 PATH3.1 去哪下?别乱下网上搜MinGW-w64 下载,前几个结果里有一堆个人打包站,版本老旧、来源不明,还经常夹带东西。推荐两条干净路线:路线一(新手首选,推荐):w64devkit到 GitHub 搜w64devkit,下载w64devkit-x.x.x.zip(约 80 MB)解压到D:\w64devkit(路径不要有中文和空格)自带的bin目录里一次配齐g.exe、gcc.exe、gdb.exe、make.exe优点:解压即用,不用装任何安装器,自带 gdb,不会出现装了编译器却找不到 gdb的经典问题。路线二(要长期用、需要包管理):MSYS2# 1. 官网下载 msys2-x86_64-xxxx.exe 并安装到 C:\msys64# 2. 打开 MSYS2 UCRT64 终端,先更新核心pacman-Syu# 3. 装工具链(约 200 MB,耐心等)pacman-S--neededbase-devel mingw-w64-ucrt-x86_64-toolchain# 4. 单独装 gdb(toolchain 里不一定包含)pacman-Smingw-w64-ucrt-x86_64-gdb装完的bin目录在C:\msys64\ucrt64\bin。3.2 配 PATH(最关键的一步)不管你走哪条路线,都要做这件事。没配 PATH,后面必报「无法将 g 项识别为 cmdlet」。按Win R,输入sysdm.cpl,回车「高级」选项卡 → 「环境变量」在**下半部分的「系统变量」**里找到Path,双击点「新建」,粘贴你的 bin 目录,例如D:\w64devkit\bin一路点「确定」(很多人只点一次就关了,等于没保存)彻底关闭 VSCode 和所有终端窗口,重新打开—— PATH 是进程启动时读取的,不重启不生效3.3 验收:这一步必须过新开一个命令提示符或 PowerShell,依次输入:g--version gdb--version两条都能打印出版本号(类似g (GCC) 14.2.0),才算成功。如果提示「无法将g项识别为 cmdlet 的名称」,不要往下走。回到 3.2,检查路径是否写错、是否点了三次确定、是否重启了终端。这一步不通过,后面 100% 会失败。四、第三步:装 VSCode 扩展(只装必要的)打开扩展面板(CtrlShiftX),搜C/C,认准发布者是Microsoft,安装。必装:扩展作用C/C(Microsoft)提供补全、跳转、红线、调试支持,是核心可选:扩展建议Chinese (Simplified) Language Pack中文界面,看个人习惯Code Runner键运行单文件,适合刷题。但它不参与调试Better C Syntax语法高亮更准确,装了不亏clangd补全更快,但必须卸载/禁用 Microsoft C/C 的 IntelliSense,否则两个引擎打架关于 clangd 的争议:clangd 的补全质量和速度确实比微软自带的好,但它配置门槛更高,而且和cpptools冲突时会出现红线乱跳。我的建议是:新手先别碰。等你对这套配置彻底熟悉了再换。装完扩展,右下角可能会弹提示检测到 #include 错误,请更新 includePath。先别管它—— 下一节解释为什么。五、第四步:四个配置文件,各管一件事现在到了最核心的部分。在项目根目录新建一个.vscode文件夹,里面会有 4 个可能的 json。新人最大的困惑是:到底哪个文件管什么?先看这张图,记住它,后面就顺了。文件管什么出问题时的症状c_cpp_properties.json只影响编辑器:补全、跳转、红线有红线,但程序能正常跑tasks.json管编译:怎么调用g.exe编译报错、找不到 glaunch.json管调试:怎么调用gdb.exe断点灰色、F5 没反应settings.json编辑器全局行为:编码、格式化、终端中文乱码、Tab 缩进全文最值钱的一句话编辑器里的红线来自c_cpp_properties.json,能不能编译成功只取决于tasks.json。所以「有红线但能跑」和「没红线但编译报错」都是完全正常的现象 —— 它们分别是两个文件的问题,别混在一起查。这句话能帮你省下大量时间,因为网上大部分VSCode C 报错的答案,根本没区分这两类问题。六、tasks.json:编译是怎么发生的(逐行讲透)先看一张图,理解按下CtrlShiftB之后到底发生了什么。核心认知:tasks.json里的args数组,就是你在终端手敲的命令。没有任何魔法。下面这份配置可以直接复制(记得把两处D:/w64devkit/bin/g.exe换成你的路径):{version:2.0.0,tasks:[{type:cppbuild,label:C/C: g.exe 生成活动文件,command:D:/w64devkit/bin/g.exe,args:[-fdiagnostics-coloralways,-g,-fexec-charsetGBK,${file},-o,${fileDirname}\\${fileBasenameNoExtension}.exe],options:{cwd:${fileDirname}},problemMatcher:[$gcc],group:{kind:build,isDefault:true},detail:编译器: D:/w64devkit/bin/g.exe}]}逐行解释(只讲你会用到的)字段含义注意事项label任务名,就是个名字后面launch.json要用它,必须逐字符一致command要调用的程序写绝对路径最稳;写g也行,但依赖 PATH 生效-fdiagnostics-coloralways让报错信息带颜色纯好看,可以删-g生成调试信息删了它,断点永远是灰色。这条是重中之重-fexec-charsetGBK让输出的中文用 GBK 编码解决中文乱码,原理见第 8 节${file}当前打开的源文件VSCode 内置变量-o指定输出文件名${fileDirname}\\${fileBasenameNoExtension}.exe输出到源文件旁边,同名 exe${fileBasenameNoExtension}是不含后缀的文件名group: { kind: build, isDefault: true }把它设为默认生成任务这样CtrlShiftB才会直接跑它关于路径写法:为什么用/而不是\两种写法 Windows 都认。但\在 JSON 里是转义字符:写D:\w64devkit\bin时,\b会被解析成退格符,路径直接变形,然后报一个让你完全摸不着头脑的错。所以要么用正斜杠D:/w64devkit/bin/g.exe,要么写双反斜杠D:\\w64devkit\\bin\\g.exe。我全文统一用正斜杠,省事。验证编译打开一个main.cpp,按CtrlShiftB,选择刚配好的任务。终端出现类似下面的输出就成功了:正在启动生成... D:/w64devkit/bin/g.exe -fdiagnostics-coloralways -g -fexec-charsetGBK main.cpp -o main.exe 生成成功,用时 0.5 秒此时源文件旁边应该出现了main.exe。七、c_cpp_properties.json:只负责编辑器的体验这个文件不参与编译,它只告诉 IntelliSense(补全引擎)去哪里找头文件。{version:4,configurations:[{name:Win32,includePath:[${workspaceFolder}/**],defines:[_DEBUG,UNICODE,_UNICODE],compilerPath:D:/w64devkit/bin/g.exe,cStandard:c17,cppStandard:c17,intelliSenseMode:windows-gcc-x64}]}关键字段只有两个:compilerPath:最重要。指向你的g.exe。插件会自动从 GCC 里读取所有内置的头文件路径,所以通常你不需要手写includePath。intelliSenseMode:GCC 64 位 Windows 就填windows-gcc-x64。填错了会补全异常。重要提醒:如果你出现「无法打开源文件iostream」这类红线,但CtrlShiftB能正常编译通过 —— 那这就是本文件的问题,去改compilerPath。反过来,如果编译时报fatal error: iostream: No such file or directory,那是tasks.json或编译器安装的问题,改这个文件没用。八、launch.json:调试是怎么发生的调试失败的 90% 原因,都在这条链路上。先看图:配置如下(把路径换成你的):{version:0.2.0,configurations:[{name:C/C: g.exe 调试活动文件,type:cppdbg,request:launch,program:${fileDirname}\\${fileBasenameNoExtension}.exe,args:[],stopAtEntry:false,cwd:${fileDirname},environment:[],externalConsole:false,MIMode:gdb,miDebuggerPath:D:/w64devkit/bin/gdb.exe,setupCommands:[{description:为 gdb 启用整齐打印,text:-enable-pretty-printing,ignoreFailures:true},{description:将反汇编风格设置为 Intel,text:-gdb-set disassembly-flavor intel,ignoreFailures:true}],preLaunchTask:C/C: g.exe 生成活动文件}]}三个必须一致的地方,对不上就调试不了:MIMode: gdb—— 用 MinGW 就填gdb,MSVC 才填cppvsdbgmiDebuggerPath——必须真实存在。报spawn gdb ENOENT就是这里错了,或者你的 MinGW 里根本没有 gdbpreLaunchTask——必须和tasks.json里的label一字不差,包括空格关于preLaunchTask,我再强调一次,因为这是最高频的坑:tasks.json里写的是C/C: g.exe 生成活动文件(注意C/C后面的冒号加空格)。你在launch.json里写成C/C:g.exe 生成活动文件或者换了半角/全角符号,F5 就会报「preLaunchTask 已终止」或者断点是灰的。最省事的做法:直接复制粘贴,不要手打。断点变灰的四个原因(按出现概率排序)tasks.json的args里没有-g→ 补上,重新生成一次preLaunchTask与label不一致→ 逐字符核对program指向了旧的 exe→ 删掉旧 exe 重新编译MinGW 里根本没有gdb.exe→ 换 w64devkit,或用 MSYS2 装 gdb关于externalConsolefalse(推荐):程序在 VSCode 的集成终端里跑,输出不会一闪而过,可以直接看true:弹出一个独立黑窗口,程序结束就关闭。新人常以为程序没运行,其实是闪退了九、settings.json:顺手把编码和终端理顺这个文件放.vscode/settings.json(只对当前项目生效),或者用全局设置。{files.encoding:utf8,files.autoGuessEncoding:true,editor.tabSize:4,editor.insertSpaces:true,C_Cpp.default.compilerPath:D:/w64devkit/bin/g.exe,code-runner.runInTerminal:true,code-runner.executorMap:{cpp:cd $dir g -fexec-charsetGBK -g $fileName -o $fileNameWithoutExt $dir$fileNameWithoutExt},code-runner.saveFileBeforeRun:true}files.encoding设为utf8,是为了保证你的源码永远以 UTF-8 保存。这一条是第 10 节解决乱码的前提。十、中文输出乱码:一张图讲透,一次解决这是评论区问得最多的问题,而且网上的答案大多是抄一段能用的,没人讲原理。所以我单独用一节说清。原理:一句话版本源文件用什么编码写,输出就得到什么编码的字节;但终端用什么编码读,是由 Windows 代码页决定的。两边不一致,就乱码。具体链路是:你的源码以UTF-8保存,你好在文件里是 6 个字节E4 BD A0 E5 A5 BDGCC 编译时原样保留这串字节程序运行时把这 6 个字节直接写给控制台简体中文 Windows 控制台默认代码页是936(GBK),它按 GBK 去解释 UTF-8 的字节 → 变成浣犲ソ顺带一提:你可能见过更离谱的锟斤拷。那是 UTF-8 字节被错误解码后,又用 UTF-8 编码了一次的产物。它的出现意味着中间经过了两轮错误转换。两种解法(任选其一,千万别混用)方案 A:源码保持 UTF-8 编译加参数(最省事,推荐)在tasks.json的args里加一行:-fexec-charsetGBK含义是:让 GCC 把字符串常量转成 GBK 字节输出。这样写出去的字节和控制台读的编码就一致了。✅ 源文件继续用 UTF-8,和 Git、跨平台协作都一致✅ 一行搞定,不用改代码⚠️ Linux / macOS 不需要这个参数,跨平台项目要分开维护配置方案 B:让控制台改成 UTF-8(更正确,跨平台一致)保持源码 UTF-8,去掉-fexec-charsetGBK,然后在运行程序前把控制台切到 UTF-8:chcp 65001.\main.exe✅ 真正跨平台一致,Linux 上也是这套⚠️ 每次开新终端都要执行一次;某些老程序在 65001 下可能有兼容问题⚠️ 别忘了这一步,否则又会乱码❌ 千万别做的事:把源文件另存为 GB2312/GBK。这在你自己机器上确实能不乱码,但代价是:Git 里中文 diff 显示异常、别人 clone 下来编译报错、换台电脑又得重存。这是技术债,不是解决方案。十一、多文件编译怎么办?到这一步,你配的都是编译当前单个文件。一旦项目有多个.cpp,就要处理这个问题。方式一:把源文件都列进 args(适合 2~4 个文件)args:[-fdiagnostics-coloralways,-g,-fexec-charsetGBK,${fileDirname}\\main.cpp,${fileDirname}\\student.cpp,${fileDirname}\\utils.cpp,-o,${fileDirname}\\${fileBasenameNoExtension}.exe]缺点很明显:每加一个文件就要改一次 json。文件超过 5 个就别这么干了。方式二:用通配符(MinGW 下可用,但有前提)${fileDirname}\\*.cppMinGW-w64 的g内置了通配符展开,所以这条在 Windows MinGW 下通常能用。但依赖运行时的 glob 支持,不是所有平台都可靠。如果你用的是 MSVC 或 WSL,这条很可能失效,请老实列出文件名,或者直接上 CMake。什么时候该上 CMake?我的分界线是5 个源文件:≤ 5 个文件:继续手写 json。零依赖、看得见每一步在干什么,出错了也好排查 5 个文件,或者要引第三方库:换 CMakeCMake 的最小配置长这样:cmake_minimum_required(VERSION 3.20) project(MyProject CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 把 src 下所有 cpp 都编进来(新增文件自动纳入,不用改配置) file(GLOB SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp) add_executable(MyProject ${SOURCES})然后在 VSCode 里装CMake Tools扩展,选好工具链,按 F5 就能直接调试 ——调试配置由扩展自动生成,你再也不用碰launch.json。这就是它最大的价值。关于要不要一上来就用 CMake:我的观点很明确 ——不要。CMake 多了一层构建系统,出错时你不会知道问题出在 CMake、编译器还是 VSCode。先用第 6 节的手写 json 跑通全部流程,再迁移。十二、完整实战:从零跑通一个带断点的程序把前面的东西串起来。新建main.cpp:#includeiostream#includevector#includestringstructStudent{std::string name;intscore;};intmain(){std::vectorStudentstudents{{张三,92},{李四,78},{王五,85}};inttotal0;for(constautos:students){std::couts.name 的分数是 s.scorestd::endl;totals.score;// ← 在这一行点一个红点}doubleaveragestatic_castdouble(total)/students.size();std::cout平均分:averagestd::endl;return0;}操作步骤:第 23 行(total s.score;)的行号左侧空白处点一下 → 出现红色实心圆按F5→ 选择 “C/C: g.exe 调试活动文件”程序会先自动编译,然后停在断点处验证成功的标志:断点是红色实心圆(灰色空心 没生效)左侧「变量」面板里能看到students、total、s的值顶部出现调试工具栏,可以单步(F10)、步入(F11)、继续(F5)调试小技巧:在「监视」面板里输入students[0],或者把鼠标悬停在变量上,就能看到vector里每一个元素 —— 前提是setupCommands里的-enable-pretty-printing生效了。没有它,你只能看到一堆看不懂的内存地址。十三、12 个高频报错速查表(建议截图保存)图片版方便截图,文字版方便复制搜索:#报错原文原因解决1无法将g项识别为 cmdlet 的名称PATH 没配或没重启 VSCode把 bin 目录加进系统 PATH,彻底重启 VSCode2undefined reference to xxx函数声明了没实现,或多文件没一起编译把源文件都写进 args,或改用 CMake3collect2.exe: error: ld returned 1 exit status最常见是main拼成了mian看上面一行的真实提示,那才是根因4error: cout was not declared in this scope忘了#include iostream或std::补头文件,或用using namespace std;5fatal error: iostream: No such file or directorycompilerPath 指错,或 MinGW 装得不完整指向...\bin\g.exe,推荐换 w64devkit6preLaunchTask 已终止,退出代码为 1编译失败,调试因此没启动先单独CtrlShiftB把编译错误解决掉7spawn gdb ENOENTMinGW 里没有gdb.exe换 w64devkit,或改miDebuggerPath8断点是灰色空心圆,未加载符号编译缺-g,或preLaunchTask不一致args 加-g;label 与 preLaunchTask 完全一致9中文乱码浣犲ソ/锟斤拷源码 UTF-8 与控制台 GBK 不一致args 加-fexec-charsetGBK10无法打开源文件stdio.h(红线)IntelliSense 找不到头文件(≠ 编译失败)改c_cpp_properties.json的compilerPath11code命令不可用 / 右键没有在终端中打开装 VSCode 时没勾选添加到 PATH重装并勾选,或手动把 VSCode 的 bin 加入 PATH12json 里注释报错 / 不允许尾随逗号VSCode 的 json 是严格模式删掉注释和多余逗号看图技巧:第 3 条和第 6 条属于假报错。ld returned 1 exit status和preLaunchTask 已终止永远不是根因,往上翻看真正的错误行。十四、配置成功的 7 个验收标准别凭感觉判断好像配好了,对着这张图逐条自测:全部打勾,你的环境就是真的配好了:终端执行g --version,能打印版本号执行gdb --version,能打印版本号F1搜C/C: Edit Configurations能打开 jsonCtrlShiftB后终端提示生成成功源文件旁出现main.exe,双击能运行F5后断点由灰色变红色实心终端输出中文不是乱码十五、几个被问爆的问题(可能和你想的不一样)Q1:为什么你的路径用正斜杠D:/,我用反斜杠行不行?行,但必须写双反斜杠D:\\w64devkit\\bin\\g.exe。JSON 里单反斜杠是转义字符,\m、\b会被解析成别的东西,然后报一个让你完全摸不着头脑的错。Q2:能不能不写绝对路径,直接写g?可以,前提是 PATH 真的生效了,而且必须重启过 VSCode。写绝对路径的好处是:换机器、改 PATH 都不会影响这个项目。我推荐绝对路径。Q3:一定要用 Code Runner 吗?不需要,而且我不太推荐新手依赖它。它本质就是帮你敲一行命令,但它的运行结果不经过launch.json,所以你没法断点调试、看不到符号。我见过不少人装了 Code Runner 之后,以为自己环境配好了,结果一调试就懵 —— 因为他压根没配tasks.json。Code Runner 适合刷算法题,不适合学调试。Q4:VSCode 一直提示检测到 #include 错误,是不是环境没配好?不一定。这是 IntelliSense 的提示,不是编译器说的。只要CtrlShiftB能编译通过,程序能跑,这个提示可以直接无视,或者按第 7 节改compilerPath消除它。Q5:程序运行完窗口一闪就没了?两个原因:一是externalConsole设成了true;二是你没在main的return前加暂停。把externalConsole改成false,输出就会留在集成终端里。Q6:Mac / Linux 上怎么配?基本一样,区别在:编译器路径不同(用which g查)、miDebuggerPath用which gdb、不需要-fexec-charsetGBK(它们默认就是 UTF-8)。intelliSenseMode改成macos-clang-arm64或linux-gcc-x64。Q7:为什么教程里都在教 MinGW-w64,你却推荐 w64devkit?因为网上那些MinGW-w64 下载链接大多是个人打包的旧版本,有的连gdb.exe都不带 —— 这正是「装好了编译器却调试不了」这个经典问题的来源。w64devkit 是官方维护的干净打包,解压即用,而且自带 gdb。十六、总结回头看,整件事其实只有三句话:VSCode 不编译也不调试,它只是按配置去调用g.exe和gdb.exec_cpp_properties.json管体验(红线),tasks.json管编译,launch.json管调试—— 出问题先分清是哪一类大部分玄学报错都有确定原因:断点灰 少了-g;乱码 编码不一致;preLaunchTask 已终止 名字对不上配置一次,能用很久。建议把这篇收藏,下次换电脑或者帮同学配环境时直接用。写在最后:想听听你的情况这篇文章里的 12 个报错,都是我在评论区和身边同学那里真实收集到的。但肯定还有我没覆盖到的坑。所以想请你帮个忙,在评论区留下:你卡在第几步?把完整报错原文(包括最后一行)贴出来,我会逐条回复,并把新的坑补进上面那张速查表 —— 你踩的坑,也是下一个人的坑。你用的是哪个工具链?MinGW-w64 / MSVC / WSL2。我很好奇大家的实际选择,这个数据也能帮我决定下一篇写什么。有争议的点欢迎来辩:比如你觉得 Code Runner 到底该不该用?一上来就上 CMake 是好习惯还是过度设计?评论区见。如果这篇帮你省下了折腾环境的两三个小时,欢迎点个赞让更多刚入门的人看到 —— 环境配置是每个 C/C 学习者的第一道坎,而它本不该这么难。下一篇预告:《launch.json高级玩法:GDB 条件断点、内存监视与多线程调试》—— 想看的同学评论区扣个 1。标签建议:VSCodeCC语言开发工具环境配置gccgdb调试技巧34c6d74a95a0a76868e2760489.png#pic_center)