VS Code 这个东西，说它是"编辑器"其实有点委屈它了。那会儿我在大学里第一次装它，跑去官网下载了个一百多兆的安装包，打开一看，白底蓝标，界面朴素得像上个世纪的产物，心里还挺不满意：怎么这么素？结果十年过去，它从一个"轻量级编辑器"变成了整个开发行业的事实标准之一。去年看到 Stack Overflow 的调查，Visual Studio Code 在开发者常用工具里占据的份额几乎是第二名的两倍，我一点不惊讶。
这篇文章我打算彻底拆一遍 VS Code，从"它到底是什么"讲到"安装过程中的各种坑"，再到 C 语言环境怎么配置、PHP 怎么用、计算机视觉学习到底该选它还是 PyCharm。内容会偏向实操，也会加入我这些年真正踩过的坑。不管你是刚下载完 VS Code 不知道从哪儿下手的新手，还是已经用它开发了一两年想挖更多效率的人，应该都能找到点有用的东西。
1. 从定位说起：VS Code 到底是一名什么样的"手艺人"
1.1 它解决的是什么问题，名字为什么叫"Code"
微软给 VS Code 的官方定位是 "源代码编辑器"，这个提法很精准。它不是传统意义上那种需要配置一大堆项目路径、平台 SDK 的"重型 IDE"，而是一个可以瞬间打开、支持丰富扩展、能应对几乎所有主流语言开发的编辑器底座。
刚开始用的时候，你会觉得它就是带语法高亮的记事本 Plus。但真正拉开差距的地方在于它的生态设计——我把 VS Code 理解为"编辑器内核 + 插件系统 + 开发者工具链"的组合，内核只做文件编辑、版本控制、终端集成、调试等基础事项，剩下的一切能力都由扩展来承担。这意味着你可以按需组装，装完 Python 扩展它就是 Python IDE，装完 Go 扩展它就是 Go IDE，一条命令都不需要额外打开。
"Code" 这个名字也很有意思。按理说微软自己有 Visual Studio 这个巨型 IDE 品牌，再推出一个带 Code 字样的产品，天然会让人以为它是 Visual Studio 的瘦身版。但实际用下来，你会发现这两者是两个物种，不是体量的差异。
1.2 与 Visual Studio 的真实区别：不是"简化版"，而是另一个物种
Visual Studio 长这样：安装包几个 GB，安装完你会看到大量组件，包括 .NET 全家桶、MSBuild、Windows SDK、各类模拟器、数据库工具。打开一个 C# 项目它要自动生成 sln、csproj 一系列工程文件，构建、测试、部署都在 IDE 内部完成。这是不折不扣的"全家桶式 IDE"。
VS Code 完全不同。它不关心你的工程结构，也没有"解决方案"这种概念，更倾向于以工作区（workspace）为单位组织文件。前端后端通吃，跨平台一致，还能通过 Remote-SSH 直接连接服务器开发，这在云开发时代太重要了。你想想，在 Visual Studio 里要调试服务器上的代码，你得先远程部署，再看日志；VS Code 里装个 Remote-SSH 扩展，打开远程目录跟本地一样顺滑，断点也能通过服务器上的调试适配器打到本地界面里。
所以如果你是 .NET 平台完整生态的开发者，Visual Studio 依然是正解；但如果你做的是跨平台 Web 开发、Python、Go、前端、物联网边缘脚本这类偏"轻量灵活"的工作，VS Code 明显更合适。很多人纠结"选哪个"，实际上是把两个工具拿到错误的比较维度上。
1.3 底层机制不能忽略：Electron 的"代价"与扩展的边界
VS Code 基于 Electron 构建，即 Chromium + Node.js 打包桌面应用。好处是前端技术栈统一，跨平台表现稳定；坏处也很直接——内存占用偏高，打开多个大项目时风扇转得跟直升机似的。我曾经同时开四个窗口，每个窗口挂五六个插件，内存直接飙到 3GB，这在原生 IDE 上几乎不太会出现。
这带来一个实际问题：你的"浏览器式编辑器"会吃你的内存资源，所以配置过低的老机器运行 VS Code 会明显卡顿，也需要我后面要说的"适度做减法"。扩展不是装得越多越好，每个扩展都在等进程里驻留着代码，拉包、监听文件、连接语言服务，日积月累的开销很可观。
2. 安装这件事：官网、语言包和系统差异，别在这些地方浪费时间
2.1 先确定从哪下载：认准官方渠道
我知道你多半已经在搜索引擎里输入过"visual studio code 官网"或者"visual studio code 下载教程"，但这里我要先说一个很容易踩的坑：Visual Studio Code 在很长一段时间内都是通过微软官方域名 releases 分发，具体入口一般是code.visualstudio.com。
为什么要强调官网？因为网上的"VS Code 下载站"鱼龙混杂。不少站点伪装成官方网站，界面高度相似，点进去下载到的却是加了附加程序的安装包，或者干脆是第三方修改版。这类版本有潜在风险，尤其是国内环境，安装完会发现多了几个莫名其妙的浏览器插件、快捷方式或者后台程序。补一条经验：看网址后缀，官方的一定是*.visualstudio.com或*.microsoft.com，其他任何二级域名都要谨慎。另外官方网址有缺省的开源版本，叫 VSCodium，去掉了遥测和微软品牌，但插件市场兼容性略有差异，我一直用官方版，一是省心，二是插件兼容不会出幺蛾子。
如果你是 Ubuntu 用户，会发现官方还提供了 .deb 和 .rpm 包，也有 snap 渠道。我这里建议：能选官方 .deb 优先选 .deb，后面我会讲到 snap 版的问题。
2.2 中文界面：chinese (simplified) language pack 与 locale 的参数细节
装完 VS Code 默认界面是英文，对部分人来说这不一定"痛苦"——英文界面能让你熟悉命令词汇，比如 File、View、Terminal，在 Stack Overflow 查问题也更顺畅。但如果确实希望改成一屏中文，方法很简单。
在扩展面板里搜Chinese (Simplified) Language Pack for Visual Studio Code，第一个结果就是微软官方语言包，安装后按提示重启即可。这里有个小细节：有些人安装完没生效，通常是这一步出了问题——它要求你在弹出通知里点击"Change Language and Restart"，或者手动通过命令面板运行Configure Display Language去选择zh-cn。不是装了扩展就自动切换的。
另外终端里的中文显示如果不正常，尤其是 Windows 自带的控制台对 UTF-8 支持不太好，通常要在设置里把terminal.integrated.profiles.windows默认配置成 VS Code 推荐的 PowerShell 版本，并确认系统区域设置里勾选了"使用 Unicode UTF-8 提供全球语言支持"，否则中文路径和日志经常乱码。
2.3 Ubuntu 24.04 的 snap 安装：看起来很美，坑也不少
Ubuntu 24.04 使用 APT 或软件中心安装 VS Code 时，默认走的是 snap 源。Ubuntu 商店里搜 code，出来的就是 Snap 版code。通过snap install code --classic可以一键安装。好处是自动更新，省心。
但我要说一个我实际遇到的麻烦：Snap 版的应用跑在沙箱环境里，对系统目录的访问权限有收紧。比如你需要让 VS Code 直接读写/usr/local/bin、/opt或者其他 snap 默认不可写的目录，可能会收到 EACCES 错误。在 24.04 上还偶发"扩展连接 node 报 Permission denied"的情况，原因就是 Snap 的安全策略与扩展动态编译器有冲突。
我的建议是：
- 如果只是日常写代码、推荐渠道就选 apt 的
snap版，省事。 - 如果你要深度做嵌入式、C 交叉编译、系统级调试，直接下载官方
.deb包安装，然后停止自动更新，用sudo dpkg -i手动安装，反而少很多权限烦恼。
到了 24.04，其实apt install code基本也是走 snap 的依赖自动转换，真正想完全脱离 snap 需要手动配置微软的 apt 仓库，或者下载 deb 包自行安装。个人推荐后者，真的不复杂。
2.4 Windows/macOS 安装里容易被忽略的选项
Windows 安装本质就是一路 Next，但有几个选项会直接影响后续体验。首先是"添加到 PATH"，一定要勾选，否则终端里的code命令用不了。其次是"创建桌面快捷方式"和"将'使用 Code 打开'添加至 Windows 资源管理器目录上下文菜单"，这两个选项我建议都勾上，尤其后者，日常开发效率的提升非常明显。右键空白处直接"Open with Code"，是高频动作。
macOS 装完主程序照理就能用，但很多人抱怨"在终端里敲 code 打不开"，这是因为 VS Code 不会默认创建全局软链。打开 VS Code，按 F1 找到Shell Command: Install 'code' command in PATH，执行一遍即可。很多教程跳过了这一步，新手会卡很久。
3. 打开编辑器后的第一件事：搭建你自己的"驾驶舱"
3.1 命令面板是你最该先记住的东西
掌握了 VS Code 的快捷键，你就能甩开鼠标；而最重要的快捷键只有一个：Ctrl+Shift+P（macOS 上是Cmd+Shift+P），命令面板。它相当于编辑器的"总控台"。几乎任何操作都能从这里触发——打开文件、运行命令、改设置、看快捷键、切换主题、安装扩展、执行 Git 操作。我平时很少去点界面上方的菜单栏，基本全靠命令面板驱动。
命令面板的一个实用技巧是输入>可以执行命令，输入@可以快速跳转到当前文件中的符号定义，输入:可以跳到指定行号。熟练了这几个前缀符号，大文件里定位内容会变得像个搜索引擎。
3.2 内置终端和 Debug 面板：真正的开发工作流
我一直觉得，VS Code 和传统编辑器的最大分水岭在于内置了完整的终端与调试器。按下Ctrl+`` 呼出的终端与项目工作目录直接联动，不用再切到另外一个终端窗口。你可以一个面板里开zsh` 跑开发服务器，另一个面板跑数据库服务，右侧窗口对齐调试器看调用栈，这是非常典型的"现代开发驾驶舱"体验。
调试器也别忽略。F5 启动调试，watch 变量、断点命中、调用栈查看一应俱全。装对语言插件后，几乎每个主流语言都能获得断点调试能力，这一点往往让很多还在"print 式调试"的新手大为惊讶。
3.3 插件机制、工作区与个人配置的持久化
VS Code 的扩展市场是它碾压同类的最大护城河。装扩展有两个入口：左侧栏方块图标，或者命令面板输入extension。安装后常常提示重载窗口，多余的操作其实可以省略，大部分扩展会立即激活。
工作区是.code-workspace文件，它记录的不只是文件夹路径，还能覆盖项目级别的设置和扩展推荐，例如团队里共享.vscode/extensions.json来统一扩展集合。我管这叫做"把个人喜好和项目约束分离"。个人偏好放settings.json，项目必须的配置放.vscode文件夹并提交到 Git，这样换机器或者新同事入职，基本零成本还原环境。
3.4 settings.json 的玄机：默认界面之外的世界
VS Code 所有设置都有默认值，不完全显示在图形界面里。想完全掌控，直接打开你的settings.json写 JSON。文件路径在核心菜单里可以找到，也可以按 F1 执行Preferences: Open User Settings (JSON)。
我已经好几年没有用过 UI 选项卡去修改设置了，全是直接改 JSON，因为可写注释、可搜索、可对比 Git 差异。例如我习惯开启"editor.minimap.enabled": true显示迷你地图，"editor.renderWhitespace": "all"显示空格，还有"files.autoSave": "afterDelay"自动保存。这些个性化配置是"顺手的驾驶舱"的第一步，千万别只看默认界面就觉得 VS Code 能力稀薄。
4. C 语言环境配置：从"能写"到"能编译调试"的完整链路
4.1 你需要什么：编译器、调试器、扩展三件套
用 VS Code 写 C/C++ 是很好的入门路径，但编辑器本身不会编译你的hello.c。它需要三样东西：编译器（比如 gcc 或 clang）、调试器（gdb 或 lldb）、以及让 VS Code 能驱动它们的扩展（官方推荐 C/C++ 扩展）。
以 Windows 为例，最常用的编译器是 MinGW-w64，因为它同时提供 gcc 和 gdb，而且与 Windows 环境的整合比 MSVC 对新手更友好。下载后解压到某个路径，比如C:\mingw64，把bin目录加入系统的 PATH 环境变量。这一步极容易被忽略，而 PATH 不正确会导致你 VS Code 终端里执行gcc --version都报不是内部或外部命令。
安装扩展的话，MS 官方的C/C++扩展（C/C++ Extension Pack 包含更多小工具）几乎是必装。它能提供 IntelliSense（智能感知）、代码跳转、调试集成。
4.2 task.json 与编译任务：把"编译"变成一条命令
新手的第一反应是用终端手动执行gcc hello.c -o hello，这没错，但效率太低。VS Code 的编译任务（task）让你按下Ctrl+Shift+B就能完成编译。它本质上是在.vscode/task.json里注册一个 shell/gcc 调用的模式。
以下是我常用的一个最小task.json：
{ "version": "2.0.0", "tasks": [ { "label": "gcc build active file", "type": "shell", "command": "gcc", "args": [ "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"] } ] }关键在于-g生成了带调试符号的可执行文件，否则后面调试的断点会全部失效。${file}是当前激活的文件路径，${fileBasenameNoExtension}是去掉扩展名的文件名。你只需要打开hello.c，按下Ctrl+Shift+B，就能生成同名 exe。
这里补充一个我翻过车的点：MinGW-w64 的老版本对 GCC 11 新特性的支持不如新版本，如果你是为了 2025 年的 C 标准特性来的，建议安装 winlibs 或从 MSYS2 源更新新版本，不要用一些古老教程里推荐的旧版 MinGW。
4.3 launch.json 与调试器：把"运行"变成"可观测"
编译完成之后，F5 启动调试需要一份launch.json。它告诉 VS Code：你要用哪个调试器、调试哪个可执行文件、启动参数是什么、在哪里停止。
标准配置长这样：
{ "version": "0.2.0", "configurations": [ { "name": "C/C++ Debug", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:\\mingw64\\bin\\gdb.exe", "preLaunchTask": "gcc build active file" } ] }preLaunchTask的值必须和task.json里的label一致，这样按 F5 时会自动先编译再启动调试。miDebuggerPath指向 gdb 的实际路径，Windows 用户如果没找到这个路径，调试器启动会报"unable to start gdb"一直无法启动调试会话。
这个preLaunchTask是最常见的坑：很多人 task 的label和 launch 的preLaunchTask不匹配，按 F5 时 VS Code 提示没有匹配的任务，要到终端里去手动编译。复制配置时务必顺手把这两个字符串对照一遍。
4.4 常见错误与排查思路：把每次报错当线索链
配置环境的报错归根到底就三类：编译器找不到、路径不对、配置指向错误。我给一个排查顺序：
- 先在终端里
gcc --version，确认所有用户能用的 PATH 里能搜到编译器。这里注意，VS Code 集成终端继承的是启动它时的环境变量。如果你给全局环境加了 PATH，得重启 VS Code 才能生效。 - 再到
.vscode/task.json里检查 command 字段，如果不写绝对路径，系统会按 PATH 找，写绝对路径时注意 Windows 里反斜杠要写成双反斜杠\\。 - 最后再看
.vscode/launch.json里 preLaunchTask 与实际 task 的 label 是否对齐，program 指向的文件是否存在。
我在公司带新人陪跑时发现，超过一半的编译失败案例都是 PATH 环境问题，剩下的是配置字符串写错。VS Code 的报错提示还算友好，把"无法打开名称为...的任务"这类提示逐字读一遍，往往就能直接定位到原因。
5. PHP 开发：把它当成一个靠谱的 PHP 编辑工具
5.1 核心组合：PHP IntelliSense 与 PHP Debug
很多人不知道，VS Code 用来写 PHP 相当顺手。市面上关于"Visual Studio Code PHP 编辑工具"的搜索热度很高，但有相当的搜索结果依然停在老教程的层面。
核心扩展就两个：PHP IntelliSense和PHP Debug。前者基于 PHP Language Server 提供自动补全、静态解析、跳转定义；后者基于 Xdebug 提供调试能力。还有phpcs这类代码规范检查工具，用来保证代码风格一致。
我见过一个"配置好了还是没补全"的常见原因：VS Code 的 PHP 扩展需要 PHP 解释器路径。默认它会去系统 PATH 里找php，但如果没有把 PHP 解释器加入变量，扩展给出的补全质量就很低。打开这个设置项：php.validate.executablePath，把 php.exe 的绝对路径填进去。
5.2 与 Xdebug 的配合：断点调试从"print_r"升级
写 PHP 的人习惯用print_r或var_dump调试，消息量大了很痛苦。Xdebug 能让 VS Code 直接打断点看变量，过程简单，但初装有个版本匹配大坑：Xdebug 3 和 Xdebug 2 的配置语法、连接端口已经从xdebug.remote_enable换成了xdebug.mode=debug，端口默认也从 9000 改成了 9003。很多教程仍然停留在 Xdebug 2，会导致连接不上。
最小 Xdebug 3 配置：
xdebug.mode = debug xdebug.start_with_request = yes xdebug.client_host = 127.0.0.1 xdebug.client_port = 9003VS Code 这边启动监听：PHP Debug 扩展的listen for XDebug命令即可。跑 PHP 内置服务器，或者 Apache/Nginx 都行，请求打过来时编辑器会弹出"已暂停"并把调用栈、变量面板都铺开。
5.3 内置服务器跟 PHP 扩展协同：一个可落地的工程示例
一个相对完整的例子：项目里用 PHP 自带服务器跑php -S localhost:8080，这个命令在 VS Code 集成终端直接启动；浏览器访问时，VS Code 通过 PHP Debug 扩展捕获调试会话。你甚至可以在 JS 代码里发起请求，PHP 断点照样能被命中，因为协议层完全透明。
这种方式很适合学习 PHP 数组逻辑、看框架源码，不用像过去的 IDE 那样先配置整个 Apache 环境。所以如果你想找"配置文件调试 PHP 的环境搭建路线"，VS Code 现在完全能扛起来。
6. 与 PyCharm 的抉择：计算机视觉学习场景到底选谁
6.1 两者各为什么都能成为"Python 开发首选"
热搜里有一个很经典的问题：学习计算机视觉时应该装 VS Code 还是 PyCharm？两个阵营都有自己的支持者。PyCharm 的优势在于深度集成 Python 虚拟环境、面向科学计算的运行配置、内置数据库工具、对 Django/Flask 等框架的结构感知，而且它是 JetBrains 全家桶的一部分，IDE 感很强。
VS Code 的优势在于轻快、配置个性化程度高、与前端和后端语言混写时的过渡顺畅，且插件市场让 Python 可以和其他语言栈共处。你要真在一个项目里同时写 Python、TypeScript、SQL，用 PyCharm 会感觉每个语言都是"二等公民"；VS Code 则不会，它把每种语言都平等地当作扩展接入。
6.2 针对计算机视觉本身，谁更有优势
计算机视觉的项目特点：大量 numpy/OpenCV 科学计算，需要频繁看变量数值、数组 shape、图像矩阵，断点调试窗口是否直观就特别关键。PyCharm 的 Scientific Mode 能把变量列表变成表格，还能直接绘制量值变化曲线，这点在调试图像处理和机器学习迭代数据时非常舒服。
但如果在 Pytorch 分布式训练或配合 C++ 部署时，VS Code 的 Python 调试器、Remote-SSH 和 C++ 调试是同一套界面，切换成本低。我可以给一个非常实用的选择判断：
- 纯 Python 为主的 CV 实验，写 Jupyter Notebook 较多、需要 debug 变量矩阵和科学运算——PyCharm 的 Scientific Mode 更省力。
- 以工程落地为目标，需要多语言联调、远程服务器训练、嵌入式部署——VS Code 更合适。
这么说可能有点"和稀泥"，但确实没有完全的单极答案。唯一的建议是：先在小项目里各用两周，以日常操作流畅度为准。趁早期切换成本低，尽早确定主工具确实重要。
6.3 如果只学 Python 基础/ML 入门，我实际推荐 VS Code
不夸张地说，学习机器学习、计算机视觉的初期绝大部分时间花在理解 API、读报错和调试逻辑上，IDE 的"科学模式"其实并没那么关键。VS Code 全平台免费、资源占用低、随处可同步配置，还会强迫你尽早接触终端、虚拟环境、代码规范这些开发基本功。PyCharm 的自动补齐、以 GUI 方式管理虚拟环境都方便，但藏着太多细节，初学者会被"无痛"带到后面出门做事时却不知所措。
有个反直觉的事实：Stack Overflow 近年的《开发者调查报告》里，Python 开发者在 VS Code 上的使用比例高于 PyCharm。做视觉、做 AI 的开发者用 VS Code 的反而大多数。市场数据比社区吵架更诚实。
6.4 计算你的真实需求：从"切换成本"和"项目边界"出发
我的经验是，选择核心工具看三个指标——项目边界、切换成本、团队协同。如果团队整个技术栈是 JetBrains 体系，项目里的运行配置、部署配置全部在 idea 格式里，硬切 VS Code 是给自己添堵；反之一个前后端混合项目，VS Code 天然是更合适的。
如果脑海中还没有清晰的评价指标，最诚实的回答是：这两个工具装哪个都不亏，真正影响学习速度的是你对终端、调试和虚拟环境的熟练度，这些底层能力与 IDE 无关。工具只是你编程认知的一个界面，随时可以换。
7. 用 VS Code 几年之后，我最想分享的几个实用心得
7.1 别把插件当装饰品，学会用 Profiles 做减法
插件装多了，VS Code 会彻底"变重"。我见过有人装了两百多个扩展，每个窗口都卡，还要骂编辑器不行。这种锅不该编辑器背。
从 2020 年之后，VS Code 加入了 Profiles（配置文件）功能，简单说就是你可以把主题、插件、设置打包成不同组合。我目前维护了三个 Profiles：一个纯 Python / DataScience 的，一个 Frontend / TS 的，一个 Remote / 服务器的。写 Python 时绝不加载前端插件，这样做的好处是启动速度和自动提示准确度双双提升。
具体操作：左下角齿轮图标 -> Profiles -> Create Profile，选需要的扩展和设置，然后切换 Profile。远程开发时还可以给 Remote 环境单独配一个精简 Profile，资源占用大幅下降。
7.2 那些平时不太注意、但非常提升幸福感的设置
我挑几个真实的设置改动，基本每一条都有人感谢我推荐过：
"editor.formatOnSave": true, "files.insertFinalNewline": true, "editor.codeActionsOnSave": { "source.fixAll": true }, "diffEditor.ignoreTrimWhitespace": false, "terminal.integrated.enableMultiLinePasteWarning": false, "explorer.confirmDelete": falseformatOnSave保证你 Ctrl+S 之后代码自动格式化，配合 ESLint 或 Prettier 能极大解放格式强迫症。insertFinalNewline会在文件结尾自动补换行，解决 git diff 里那种"最后一行没换行"的烦人提示。theme方面，我喜欢Editor: Font Size调到 15，Line Height调到 1.7，阅读体验比默认值舒服不少。
7.3 基于多年经验的安全习惯：备份与版本控制
.vscode目录应该进入你的 Git 仓库。很多人觉得这只是本机配置，提交了会污染代码，但实际上.vscode/settings.json和.vscode/extensions.json恰好能让团队保持一致的开发环境和推荐插件。真正不该入库的是.vscode/workspaceStorage这类本地缓存目录，需要手动在.gitignore里排除。
VSCode 的同步功能我也关了，改用设置同步（内置的 Settings Sync）把个人配置备份到 GitHub 账号，这样换机器之后登录账号，配置、插件、快捷键几十秒恢复。这套流程比手动导插件列表要靠谱得多。
8. 最后一步，从"能跑"到"好用"：我的完整收尾清单
眼看着篇章不短，读者最需要的是行动路径。我综合自己多年的经验，给一份可直接照着做的收尾清单：
- 打开官网下载安装包，Windows 勾选 PATH、右键菜单；macOS 记得安装
code命令；Ubuntu 高级用户直接用.deb包代替 snap。 - 安装中文语言包或者保留英文，按个人偏好。
- 花二十分钟浏览命令面板，练习
Ctrl+Shift+P、Ctrl+P、Ctrl+B（切换侧边栏）、Ctrl+`（打开终端）。 - 建立一个简单项目，手动写一遍
task.json和launch.json的编译调试链路，理解每个字段含义。 - 根据语言方向装少量核心插件，避免初期盲目堆插件。
- 用 Profiles 按工作流拆分环境，想把个人配置备份到云端就开启 Settings Sync。
- 对于 Python/CV 项目，先用 VS Code 熟悉终端、虚拟环境和调试器，再把 PyCharm 作为备选项对比体验。
我个人在配置 VS Code 上踩过的最大弯路，就是一开始把它当成"装完扩展就能用"的工具，忽略了学习它的任务系统、调试配置和终端联动。真正把这几样弄通之后，会发现工具体验会有一个陡峭的上升曲线，这个过程比纠结选哪个编辑器有价值得多。如果你的某个项目刚好被文章里描述的问题卡住，照着上面的步骤过一遍，应该能把大部分拦住你的环境问题顺手解掉。
