如何在 VS Code 优雅地通过 F5 调试 Go+React 全栈项目

如何在 VS Code 优雅地通过 F5 调试 Go+React 全栈项目

也就是今天下午的事。

我手头有一个全栈项目，结构很经典：根目录下分了 backend（Go后端）和 frontend（React前端）。每次开发都要开两个终端：一个跑 go run，一个跑 npm run dev，调试的时候还要切来切去，体验非常割裂。之前古法开发的时候我一边用webstorm开发+调试，一边用goland开发就调试。现在vibe coding比例逐渐增大，还是合在一个vscode项目里方便一点（毕竟人还是需要断点调试的）。

我想要的是：按一下 F5，前后端同时启动，断点随便打。

这就遇到了一个很烦的问题：我的 go.work 文件在 backend 目录下。如果在根目录直接启动调试，Go 编译器立马报错找不到模块；如果在根目录放一个 go.work，又觉得把项目根目录弄得很乱（强迫症表示不能忍）。

折腾了一番，终于找到了一套不污染根目录且无缝调试的配置方案，趁热记录一下。

Go Modules 的路径

通常我们会在项目根目录放 go.work 来管理多模块，但如果你的后端代码深藏在 backend 目录下，根目录其实跟 Go 没啥关系。

我想达到的效果是：完全隔离。

• VS Code 打开根目录。
• 但 Go 插件只认 backend 下的配置。

解决方案： go.toolsEnvVars

VS Code 的配置其实非常强大。我们不需要在物理文件上做妥协，只需要告诉 IDE：“编译的时候去下面找配置”。

在 settings.json 里加上这一段：

{
    "go.toolsEnvVars": {
        "GOWORK": "${workspaceFolder}/backend/go.work"
    }
}

这一步非常关键！它告诉 gopls（Go语言服务器）和调试器，虽然我打开的是根目录，但环境变量 GOWORK 实际指向了子目录。这样代码跳转、自动补全瞬间就正常了，而且根目录干干净净。

配置后端调试 (Launch.json)

接下来配置 launch.json。不仅要指定程序入口，还要注意两个点：

1. cwd (工作目录)：很多后端程序启动时会读当前目录下的 config.toml 之类的文件，所以必须把运行目录指对。
2. env：再次强调 GOWORK，确保运行时环境正确。

{
    "name": "启动后端",
    "type": "go",
    "request": "launch",
    "mode": "debug",
    "program": "${workspaceFolder}/backend/main/main.go",
    "cwd": "${workspaceFolder}/backend/pack", // 配置文件都在这里
    "env": {
        "GOWORK": "${workspaceFolder}/backend/go.work" // 再次确保运行时能找到模块
    }
}

配置前端调试

前端通常我们会用 Chrome 或 Edge 调试。这里有个小技巧，不用非得在 VS Code 里跑 npm run dev（虽然也可以配置 Task），我习惯在终端跑服务，然后让 VS Code 附加浏览器调试。

{
    "name": "调试前端 (Edge)",
    "type": "msedge",
    "request": "launch",
    "url": "http://localhost:5173", // Vite 默认端口
    "webRoot": "${workspaceFolder}/frontend"
}

Compound (复合调试)

这是最爽的一步。在 launch.json 的最后，用 compounds 把上面两个配置组合起来：

"compounds": [
    {
        "name": "全栈调试 (前后端一起)",
        "configurations": [
            "启动后端",
            "调试前端 (Edge)"
        ]
    }
]

最终效果

现在，调试面板里选中 “全栈调试”，按下 F5。

你会看到：

1. Go 后端服务启动，终端输出日志。
2. Edge 浏览器自动弹出，加载前端页面。
3. 你在 Go 的 API 接口打个断点，前端点个按钮，后端断点停住了。
4. 你在 React 组件里打个断点，前端断点也停住了。
5. 项目根目录依然清清爽爽，没有莫名其妙的 generated files。

舒服了。

后记

大概是在去年，当我第一次听到 Vibe Coding 这个词时，内心其实觉得挺搞笑的，甚至带有一丝不以为然。

尽管早在 2022 年初，我就已经作为内测用户接触了 GitHub Copilot——那时 ChatGPT 尚未横空出世，Copilot 背后运行的似乎还是特调版的 GPT-3.0（Codex），其功能也相对单一，主要局限于代码补全。

但自从去年换了工作以后，情况发生了变化。我开始大规模地利用 Copilot 的 Agent 能力来辅助阅读代码，或是编写一些小型功能模块。

随着时间的推移，我明显感觉到 Agent 的技术水平和理解能力在飞速进化。它不再局限于补全几行代码，而是能够独立完成庞大的功能开发，甚至能够深入理解拥有几百万行代码的超大型项目的上下文与整体架构。

尤其是当部门为我们配置了 Claude Code 之后，在融合了特定的 Skill 和 MCP后，其展现出的业务能力简直可以用可怕来形容。而这些阐述了业务细节和架构的md文档，大多数其实也是ai在工作中总结，或读取云文档生成的。

说实话，我害怕了。

只有最后一段是手写的 ：），当然也不尽然