企业官网建设流程全解析

如果抱着“装个 VS Code Qt扩展就能像官方 IDE 那样拖控件”的期望，那你大概率会失望。但要是你的目标是：留在 VS Code 编辑器生态里，同时获得接近原生 IDE 的补全、跳转、构建、调试体验，那 VS Code Qt扩展从 1.12.0 版本开始，确实已经值得正经看待了。这篇文章基于 VS Code Qt扩展 1.12.0 的实际使用，结合我大半年从调试到日常项目开发的真实经历，重点讲清楚它到底能做什么、配置时哪里最容易翻车、升级后哪些地方感知最明显，以及我替你先踩过的几个典型坑。适合刚接触 Qt 开发、又不打算迁移到官方 IDE 的朋友参考。

1. 为什么我在VS Code里做Qt，而不是一直待在官方IDE

1.1 官方IDE的强项与我的日常冲突

Qt 官方 IDE 其实做得不差，尤其是 Qt Creator——它的会话管理、套件（Kit）切换、QML 调试、UI 文件编辑器，都是围绕 Qt 开发流程量身定做的。如果你把一个项目从头到尾都放在同一个 IDE 里，体验绝对顺畅。但问题是我的工作流不总围绕同一个项目转：平时要写 Python 脚本、改 TypeScript 前端、维护 CMake 构建脚本，还会打开各种纯文本配置。让我每个项目都切到 Qt Creator，再单独开一个 VS Code 做其他语言，窗口管理成本高得离谱。

还有个更现实的问题：团队协作时，代码评审、Git 操作、远程开发（通过 SSH 连服务器或开发机）这套流程基本都沉淀在 VS Code 生态里。Qt Creator 在这块的集成不是没有，但用起来总觉得隔了一层。比如远程开发时，Qt Creator 的延迟和索引速度会明显拖后腿，而 VS Code 的 Remote 机制已经非常成熟。对我来说，需要一个“能覆盖 Qt 开发需求、又不打乱既有工作习惯”的编辑器方案，VS Code 加 Qt 扩展就是这个折中点。

1.2 这个扩展真正补上的三个拼图块

在早期，VS Code 里做 Qt 开发也不是不行，但属于自己动手拼凑：装 C/C++ 扩展做补全，用 CMake Tools 管构建，再手动配置 tasks.json 和 launch.json 做调试。能跑，但很多东西是碎的。比如 qmake 工程没有原生支持，Pro 文件不会被解析；Qt 的头文件路径要手动包含，不然 IntelliSense 一片红；调试时 Qt 的信号槽、字符串类型在变量窗口里全是内存地址，根本没法看。

VS Code Qt扩展（我习惯直接叫它 Qt 扩展）解决的正是这些碎片问题。它补齐的三块拼图在我看来最重要：

第一，对 Qt 项目的识别能力。基于扩展设置里的 Qt 路径，它能自动拿到 Qt 的头文件目录、库目录和工具链信息，不需要手动往 C/C++ 配置里塞一堆 includePath。

第二，对 CMake 的深度配合。虽然实际的构建仍然依赖 CMake Tools，但扩展会做好套件识别，让“构建、运行、调试”这一套动作变成真正可点击的操作，而不是每次去改 JSON 配置。

第三，对 Qt 专属概念的理解。比如 Qt 的元对象系统、信号槽语法、QML 类型，它的代码高亮和补全逻辑能明显识别出这些内容，而不是把connect(...)当成普通语法错误。

坦白说，这三块补上之后，日常写 Qt 的体验已经从“能用”变成了“顺手”。这也是我愿意专门花一篇文章聊它的原因。

2. 1.12.0这次升级，真正影响日常体验的几个变化

2.1 从版本演进看这次更新的侧重点

版本号从 1.11 跳到 1.12.0，属于典型的次版本迭代。按我对这类扩展的观察，次版本号通常是功能增减和体验优化的主战场，不会像大版本那样做破坏性重构。结合我在升级前后跨了几个星期的使用对比，这次更新的侧重点明显集中在一块：让扩展更好地融入 VS Code 本身的工作流，而不是继续造自己的轮子。

所谓“融入 VS Code 工作流”，具体点说就是：你不需要为了 Qt 去学习一套全新的 UI，也不需要记住某个专用面板的入口。所有功能都以命令的形式藏在 VS Code 的命令面板里，比如切换套件、查看 Qt 版本、打开 Qt 文档等。这种设计思路在 1.12.0 里体现得更充分。另外，扩展在配置项上做了收敛——过去一些藏在代码里的选项被整理到设置界面，新手不再需要去读文档才知道某个功能怎么开。

从感受来讲，这次升级后最明显的变化不是多了某个惊艳功能，而是“没那么多烦人的提示了”。旧版本里偶尔会弹出来的“未找到 Qt 套件”“请配置 CMake 工具链”这类干扰性报错，在新版本里被控制得更克制，只有当扩展真的无法确定环境时才会提示。这个细节对日常体验的提升其实比新功能还重要。

2.2 我实测下来感知最明显的三个位置

先说 QML 相关的高亮和补全。升级到 1.12.0 后，我打开一个.qml文件，明显感觉颜色标注更符合 Qt 的语法角色：属性、信号、元素类型、导入语句各有各的配色，和默认主题的适配也更好。补全响应也比以前跟手，输入到一半暂停时，候选列表弹出的速度基本不需要等待。

第二个感知明显的位置是状态栏里套件（Kit）信息。以前版本偶尔会显示不出来，或者显示的不是当前 CMake 预设对应的编译器。这次升级后，状态栏的套件显示稳定了很多，切换套件时的联动也快。这个功能看起来不起眼，但如果你经常在 MSVC 和 MinGW 之间切来切去，就知道套件显示错误有多误导人。

第三个位置是构建输出窗口的报错解析。C++ 编译器的报错信息通常又长又绕，扩展能把 Qt 相关的常见错误（比如某个Q_OBJECT宏没加、信号签名不匹配）在“问题”面板里折叠得干净一些，点击问题能跳到对应代码行。这个能力在旧版就有，但 1.12.0 对 Qt 6 的报错兼容更准确，误报和漏报都少了一些。

我还是要多说一句：以上观察是基于我自己的配置和工作流。如果你用的编译器版本、CMake 版本或者 Qt 版本跟我差异很大，感知可能完全不同。但总体方向不会变——这个版本追求的是“少打扰、更准确”，而不是塞新概念。

2.3 升级前后的兼容性风险与回退办法

扩展升级和 Qt 开发环境的兼容性问题，主要出在两个地方：一是扩展版本要求的 VS Code 最低版本，二是 CMake Tools 扩展的版本是否配套。1.12.0 发布时，我注意到它对旧版 VS Code 的兼容线画得比较高，如果 VS Code 停留在一年前的版本，安装扩展时可能会收到“不兼容”的警告。

这种场景下不建议硬装。要么升级 VS Code，要么手动安装旧版本的扩展。VS Code 扩展市场里，每个扩展的详情页右侧都有“Install Another Version”入口，可以选旧版本安装。我在一次远程开发机上就遇到过 VS Code 版本太旧导致扩展无法加载的情况，当时直接回退到之前使用的 1.11.x 版本，等开发机环境升级后再切回 1.12.0。这个回退操作不会影响整个项目的配置，扩展的设置项基本都是 JSON 存储，新旧版本之间兼容性较好，最多就是某些新配置项不生效。

另外一个兼容性动态是 Qt 6 和 Qt 5 的路径差异。1.12.0 对 Qt 6.5 及以上版本的适配更到位，如果你还在用 Qt 5.15，某些提示逻辑可能反而“过于新”。实际表现是：扩展识别到了 Qt 5 的版本号，但在某些功能上还是按 Qt 6 的方式去处理。这个问题不致命，代价是偶尔的误报。如果你遇到这个情况，一个有效的办法是在设置里把版本选择逻辑改成手动指定，而不是自动探测，具体方法我在下一部分会细说。

3. 首次配置的完整流程与最容易出错的位置

3.1 前置依赖：编译器、CMake与调试器的正确组合

任何 Qt 项目跑起来都需要三样东西：Qt 库、编译器、构建工具。VS Code 侧还需要几个扩展：Qt 扩展本体、C/C++扩展、CMake Tools 扩展。检查版本时我最常遇到的问题是：只装了 Qt 扩展，没装 CMake Tools 就点构建按钮，结果弹出一堆看不懂的错误。

这三者的组合方式，我按场景拆一下：

• Windows 下如果用 MSVC，需要提前安装 Visual Studio 生成工具，且要在 VS Code 里打开“开发者命令行”环境后才能正常调用cl.exe。直接开普通终端会找不到编译器。
• Windows 下如果用 MinGW，需要确保mingw32-make或 CMake 用的生成器与 Qt 包匹配。这里有个经典坑：Qt 6 的 MinGW 包自带一套 MinGW 版本，和你系统里自己装的 MinGW 版本不一致时，链接阶段会报一堆奇怪错误。
• Linux 下相对省心，系统包管理器里安装的g++、gdb、cmake基本能用，但要注意 Qt 是从发行版仓库装的还是从 Qt 官方安装器装的，两者的路径结构不一样，会影响后续配置。

调试器方面，Windows 配 MinGW 用 GDB，配 MSVC 用 VS 自带的调试器（VS Code C/C++ 扩展有专门支持）。Linux 用 GDB。macOS 上一般用 LLDB，不过 Qt 官方对 macOS 的支持已经越来越边缘化，我这边不做重点讨论。

3.2 扩展配置项逐个拆解

安装完扩展后，第一件事是打开设置面板，搜索 Qt 相关配置项。我逐个说关键项：

第一个是 Qt 的可执行路径或安装目录。这个选项决定了扩展能找到哪些套件。Windows 下通常指向类似D:/Qt/6.7.2/mingw_64的目录，而不是D:/Qt根目录。很多人在这一步填错，导致扩展扫描不到任何套件。如果你填的是安装器根目录，扩展应该能自动发现底下所有版本，但逻辑会多走一层，偶尔会漏掉。

第二个是 C/C++ 扩展的配置模式。Qt 扩展负责把 Qt 头文件目录反馈给 C/C++ 扩展，所以 C/C++ 扩展的IntelliSense模式要设为针对对应编译器的模式，比如gcc-x64或者windows-msvc-x64。不设置的话，C/C++ 扩展有时会用默认的linux-gcc-x64，在 Windows 上就会出现“头文件找不到，但编译能通过”的怪象。

第三个是 CMake Tools 的预设管理。新版扩展在工程里如果有CMakePresets.json，会优先按预设里的配置来关联套件。我的建议是：如果你同时用了 qmake 和 CMake 的工程，不要混用，一个工作区最好只管一种构建系统，否则扩展在选择“当前构建工具”时容易分辨不清。

下面是我的一个最小化.vscode/settings.json示例，主要配置项都写上了：

{ "cmake.configureOnOpen": true, "cmake.autotraceConfigure": false, "qt.qtPath": "D:/Qt/6.7.2/mingw_64", "qt.autoDetectQtPath": true, "C_Cpp.intelliSenseMode": "gcc-x64", "C_Cpp.default.compilerPath": "D:/Qt/Tools/mingw1310/bin/g++.exe" }

这里面有个细节值得注意：qt.qtPath和qt.autoDetectQtPath同时设置时，以手动指定为准。如果手动指定的路径无效，扩展会尝试自动检测，这个回退逻辑本身是好的，但如果你装了多个 Qt 版本，自动检测可能选中了你不想用的那个。建议的场景是：固定一个路径，省心。

3.3 用一个最小工程跑通「F7构建 + F5调试」

配置完成后，最好用一个最小的 Qt Widgets 工程做验证。我通常会用 CMake 工程来试，因为你以后的项目大概率也是 CMake 管理，提前把这条路走通，后面能省很多事。

创建一个最简单的目录结构：

minimal_qt_app/ CMakeLists.txt main.cpp

CMakeLists.txt只做最基本的事情：

cmake_minimum_required(VERSION 3.16) project(minimal_qt_app VERSION 1.0.0 LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt6 REQUIRED COMPONENTS Widgets) qt_standard_project_setup() qt_add_executable(minimal_qt_app main.cpp) target_link_libraries(minimal_qt_app PRIVATE Qt6::Widgets)

main.cpp也不需要花哨，一个能弹出空窗口的最小程序就够：

#include <QApplication> #include <QMainWindow> int main(int argc, char *argv[]) { QApplication app(argc, argv); QMainWindow window; window.show(); return app.exec(); }

打开工程后，确认右下角或状态栏出现 CMake 配置成功的提示。按 F7 触发构建，如果构建成功，会生成可执行文件；按 F5 调试时，VS Code 会首次弹出调试配置选择，扩展一般会提供 Qt/C++ 相关的现成配置。如果没弹出来，需要手动创建一个.vscode/launch.json，核心配置大致是：

{ "version": "0.2.0", "configurations": [ { "name": "Launch minimal_qt_app", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/Desktop_Qt_6_7_2_MinGW_64_bit-Debug/minimal_qt_app.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "D:/Qt/Tools/mingw1310/bin/gdb.exe" } ] }

这中间最容易翻车的地方是program路径。CMake 生成目录的名字如果带套件信息（像示例里的Desktop_Qt_6_7_2_MinGW_64_bit-Debug），不同电脑上可能完全不一样。建议直接在构建完成后找到可执行文件的实际路径，复制过去，别手打。用调试器跑一遍，能停在断点上，就算通了。

4. 日常开发里最高频的五个能力，以及我的使用方式

4.1 补全与跳转：clangd互补配置的经验

Qt 补全质量取决于 C/C++ 扩展提供的 IntelliSense，而 IntelliSense 有几个老大难问题：模板代码太多时响应变慢、部分 Qt 宏展开不正确导致误报。我的做法是装 clangd 作为第二套补全引擎，并禁用 C/C++ 扩展的部分补全功能。听起来像绕路，但实际效果更稳。

clangd 最大的优势是解析速度稳定，而且对 C++ 标准库和 Qt 头文件的理解基于真实的 AST，不会出现“明明编译通过，代码却标红”的尴尬。但要让它正确工作，需要给 clangd 提供编译参数。CMake 工程在生成时如果有compile_commands.json，clangd 会自动读取，前提是你把生成器设为 Ninja，或者在 CMake 配置里加了-DCMAKE_EXPORT_COMPILE_COMMANDS=ON。

VS Code 里同时启用 C/C++ 扩展和 clangd，会导致提示栏出现两套补全候选。我的处理方式是：在 clangd 的设置里把内存限制调高到 4096，同时把 C/C++ 扩展的自动补全关掉，只保留它的调试能力。这个取舍看起来很反直觉——装了官方扩展却把补全关了——但如果你是老手，大概率能理解：补全引擎宁缺毋滥，一个频繁出错的补全比没有补全更让人崩溃。

4.2 构建任务与CMakePresets的搭配技巧

Qt 扩展和 CMake Tools 搭配时，构建按钮默认走的是 CMake 生成的那套目录，通常没问题。但如果你想在命令行里复用同一套构建逻辑，就得用 CMakePresets。这个文件不仅能固化配置，还能让团队成员之间少很多“为什么你能编译我这儿不行”的争吵。

我的常用预设长这样：

{ "version": 6, "configurePresets": [ { "name": "debug", "displayName": "Debug", "generator": "Ninja", "binaryDir": "${sourceDir}/build/debug", "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug", "CMAKE_PREFIX_PATH": "D:/Qt/6.7.2/mingw_64" } } ], "buildPresets": [ { "name": "debug", "configurePreset": "debug" } ] }

这里面CMAKE_PREFIX_PATH是关键。Qt 的 find_package 靠这个变量定位库文件，少了它，CMake 会报 “Could not find a package configuration file provided by Qt6”。

构建时，如果你用的是 Ninja 生成器，Qt 扩展和 CMake Tools 的配合会非常顺。Ninja 的增量构建速度通常比默认的 Unix Makefiles 或 MinGW Makefiles 快一大截。我第一次从 Makefiles 切到 Ninja 后，大项目的重新构建时间几乎减半，这收益来得太直观了。唯一需要注意的是，Ninja 需要单独安装，很多发行版的包管理器里名字是ninja-build，在 Windows 下用 Qt 自带的也行。

4.3 断点调试：附加进程和Qt信号槽断点的特殊处理

Qt 程序的调试里，最常遇到的需求有两个：一个是调试程序启动后的某个逻辑分支，另一个是调试已经运行的进程。后者在 Qt 开发里非常常见，因为你要观察的是程序运行到某个状态时的问题，而不是从头启动复现。

附加进程时，launch.json 里的请求类型要改成attach，并填上进程名或 PID。我在 Windows 上做附加调试时踩过坑：Qt 程序编译模式是 Release，GDB 附加后发现变量全是void。排查了很久才明白是编译优化导致的符号缺失。建议附加调试前先确认构建类型是 Debug，并关掉优化选项：

set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0 -g3")

Qt 的信号槽断点也有学问。想在 lambda 表达式里断开，直接在 lambda 体内加断点就行；但想在connect语句处看信号如何触发，就没那么简单。GDB 不能直接在信号分发内部下断点，一般的做法是在槽函数入口加断点，然后查看调用栈。如果调用栈里出现QMetaObject::activate之类的函数，说明信号确实分发过来了。理解这个逻辑比纠结“为什么断点不生效”更有用：信号槽的本质是函数调用，断点不生效往往是因为槽函数没被调用，而不是调试器坏了。

4.4 QML编辑体验：语法检查与实时预览边界

QML 的实时预览一直是 VS Code 的短板。Qt 官方 IDE 有 QML 调试器和交互式预览，VS Code 里暂时做不到同级别的体验。1.12.0 在这方面没有魔法，它做的是把语法检查和高亮做扎实。

实际使用中，我用扩展写.qml文件，能明显感觉到对property、signal、onClicked这类语法的识别很准确，配色贴切，补全候选里也能列出 QML 元素类型。但这个能力依赖于 QML 语法服务器，如果你的项目里 QML 文件使用了自定义的注册类型（qmlRegisterType注册的），扩展可能无法识别这些类型，补全列表里不会出现它们。

这种情况下我一般不会硬凹，而是依赖编译时和运行时的报错来兜底。QML 是动态语言，语法检查只能发现拼写问题，真正的逻辑错误要靠程序跑起来后的报错信息。扩展里比较实用的是“QML 工具”的 lint 功能，它能指出像“访问了不存在的属性”这类常见问题，算是动态语言里少有的静态保护。

5. 新装或升级后我实际踩过的坑：症状与排查链路

5.1 症状一：完全体配置下代码跳转失灵

升级到 1.12.0 后，一度出现 F12 跳转完全失灵的情况。点击跳转要么没反应，要么跳到头文件的错误分支。第一次遇到时我以为是新版本引入的 bug，后来静下心排查，发现根因并不在扩展本身，而是 clangd 缓存失效。

排查链路是这样的：先确认 C/C++ 扩展的跳转是否工作，把 clangd 停掉试，跳转恢复正常了，说明问题在 clangd。然后检查compile_commands.json是否指向了旧路径——因为 CMake 缓存没清，生成的编译命令里还带着旧 Qt 版本的绝对路径。清掉 build 目录重新 configure，再到 clangd 的设置里手动触发一次“Reset Clangd Server”，跳转就正常了。

这个坑的教训是：升级扩展版本之前，先清理一遍工程里的生成目录。CMake 的缓存信息一旦带着旧的绝对路径，新的扩展就算再聪明，面对不一致的环境也容易出错。

5.2 症状二：调试器里看不到Qt容器的内容

调试时观察QString变量，变量窗口里显示的是一长串内存地址和内部指针，完全没有可读性。这个问题在 Windows + MinGW + GDB 的组合下尤其常见。

进一步排查发现是缺少调试辅助的“pretty-printer”。GDB 默认不知道怎么把QString的内部结构转成可读字符串，需要加载 Qt 提供的打印脚本。Qt 安装目录里通常有对应文件，比如：

D:/Qt/6.7.2/mingw_64/share/qtcreator/debugger/

这个目录下有一些 python 脚本，可以通过配置 GDB 的自动加载来启用。在 VS Code 的launch.json里，可以通过setupCommands来预执行 GDB 命令：

{ "name": "Launch with pretty-printer", "type": "cppdbg", "request": "launch", "setupCommands": [ { "description": "Enable pretty-printing for Qt types", "text": "-enable-pretty-printing", "ignoreFailures": true } ] }

如果上面还不够，就需要找到 Qt Creator 提供的qttypes.py之类的文件，手动source到 GDB 会话里。这个过程比较繁琐，我可以负责任地说：搞通一次之后，调试 Qt 容器类型的体验会好一个数量级，值回折腾。

5.3 症状三：构建任务总能找到另一个Qt版本

这个问题我在配多版本 Qt 时频繁遇到。系统里装了 Qt 5.15 和 Qt 6.7.2，CMake 配置时find_package(Qt6)却报错说找到了 Qt5 的路径。听起来离谱，但根因是CMAKE_PREFIX_PATH同时包含了两个 Qt 的路径，CMake 的查找规则可能先搜到了 Qt5 的配置。

我的排查思路是：把所有预设和缓存的CMAKE_PREFIX_PATH打出来看，一般多版本冲突都是路径污染。设置里明明写的是 Qt6 的路径，但 CMakeCache.txt 里可能残留了 Qt5 的条目。解决办法是删掉 build 目录，从干净的配置开始。如果还不行，就要检查系统环境变量CMAKE_PREFIX_PATH是否设置过，很多人在某次安装 Qt 时写过环境变量，后来忘了删。

这种问题很难一次定位，因为报错信息只会说“找不到 Qt6”，不会告诉你“因为找到了 Qt5 所以放弃了 Qt6”。记住这个逻辑，下次看到类似报错，直接查缓存和路径。

5.4 症状四：文档链接全部跳到404

扩展里有个“打开 Qt 文档”的功能，点击后发现浏览器打开了本地 HTML 文档但地址错误，页面内容完全不存在。这个问题不难，但很恼人。

排查后发现是qt.qtPath配置的目录里没有对应版本的文档子目录。Qt 官方安装器默认可以不装文档，如果你当初安装时没勾选 Documentation 组件，文档目录就不存在。扩展按路径去找，找不到就垮掉。

解决办法有两种：一种是在 Qt 维护工具里补装文档组件，另一种是手动指定文档路径到一个已有的 doc 目录。第二种方式对新手更友好，因为补装需要重新跑安装器，还要登录账号、过渡时间。如果你卡在这步，直接在设置里找文档相关字段，填一个有效的目录就行。

6. 使用边界与我的最终选择逻辑

6.1 什么情况下我不建议用这套组合

VS Code Qt扩展虽然好用，但它不是万能钥匙。如果你遇到下面几种场景，我更建议回到官方 IDE 或者其他专用工具。

第一个是大型单库项目的全量索引。代码超过几百万行的规模时，VS Code 的补全和跳转性能会明显劣化，即使 clangd 也会吃力。Qt 官方 IDE 在这方面做了更多性能优化，比如延迟加载文件、分块索引，实际体验会稳定一些。

第二个是重度 QML 调试。如果你的工作内容是做复杂 QML 动效、调试场景树、查看对象属性实时变化，VS Code 目前做不到官方 IDE 那个深度。偶尔写几个 QML 页面没问题，但主业是 QML 交互开发的话，强行用 VS Code 是跟自己过不去。

第三个是 Windows 下必须用 MSVC 且需要集成 UI 设计器的工作流。虽然扩展能提供代码层面的完整支持，但.ui文件的拖拽编辑在 VS Code 里基本是缺失的。虽然有外置的 Qt Designer 可以调用，但跨工具切换本身就是一种损失。UI 工作是 Qt 开发的半壁江山，这一块短板需要注意。

6.2 我的工作流总结与个人体会

我目前在用的组合是：VS Code + Qt扩展 + CMake Tools + clangd，构建用 Ninja，调试用 GDB（加 pretty-printer）。这套配置覆盖了我日常 80% 的 Qt 开发工作。剩下 20% 的 QML 密集调试和 UI 设计工作，我会临时开回官方 IDE。切换成本并没有想象中高，因为 CMake 工程在两个工具之间是通用的，不会出现“换工具就要改项目结构”的情况。

从我个人的喜好来看，最让我满意的不是某个单一功能，而是这套组合里“工具感”对了：编辑器归编辑器，扩展归扩展，构建和调试都是公开的标准格式，出了问题能一步步沿着逻辑去查，而不是在一个封闭 IDE 里对着莫名其妙的弹窗发愁。这种感觉，可以说喜欢自由折腾的人，用过一次就回不去了。