掌握VS Code 第14讲——启动配置：launch.json、复合启动与本地远程统一

访问DeepWrite

排版设置

在这里统一调整字体、字号、目录停靠位置和正文显示方式，不挤占右上角工具条。

字体

字号

目录层级

目录停靠位置

决定目录固定在左侧还是右侧，方便按手势习惯或演示场景调整。

正文显示方式

决定正文是否保留独立阅读卡片背景；关闭后正文会更贴近整页背景。

中文长文先试中文经典；英文长文先试 English Essay。目录默认显示到 H2，可按需要扩到 H4；目录位置和正文显示方式也可以在这里统一调整。

朗读菜单

直接在 HTML 页面内朗读，下载文件和独立分享页都可使用。这里只保留最少功能。

当前状态：未开始

语音

语速 0.82x

高亮级别

浏览器支持时会记住上次朗读位置。

全屏专注式阅读说明

这页优先保留鼠标与触摸操作，让阅读、选词、点击链接和查看目录互不打扰。

单击正文空白区：同时显示或隐藏主题区和目录。
开始滚动正文：自动进入专注态，减少阅读时的视觉干扰。
双击正文空白区：进入或退出全屏专注式阅读状态。
全屏专注时，按 Esc 或点击“退出全屏专注”：退出全屏。

掌握VS Code 第14讲——启动配置：launch.json、复合启动与本地远程统一

一、场景钩子

前两讲我们已经把"能跑起来调试"（第12讲）和"把跑起来这件事自动化"（第13讲）讲透了。但还差最后一块拼图没说破：程序到底怎么"起起来并挂上调试器"这件事本身，值不值得专门配置一份文件？

先想一个画面。你每次想调试，得先在终端手动把服务起起来、记住进程号、再到编辑器里手动 attach 调试器，三步里任何一步错，断点就不命中。再想另一个：你的项目是前后端两个进程，你想同时调试它们——前端改个请求、后端改个处理，最好两个都挂着断点。你现在的做法是开两个终端各自起、再分别 attach，协调起来手忙脚乱，常常"前端断了后端没断"。

核心问题由此而来：launch.json 是什么、为什么"怎么把程序起起来并挂上调试器"值得固化成一份配置？复合启动怎么把多进程串成一个动作？本地调试和远程调试又怎么统一成同一份体验？本讲处理三件事：第一，启动配置的机制——launch 与 attach 两种模式的本质区别、复合启动怎么工作；第二，它从哪来——从"每次手动拼启动命令"到"声明式调试入口"；第三，也是重头戏——怎么把"怎么起、怎么挂、怎么验"沉淀成团队共享、AI 也能照着跑的配置。

二、机制讲透：启动配置是"调试入口的声明书"

先确立一件事：你按 F5 时，编辑器不是凭空知道"该起哪个程序、带什么参数、要不要停在第一行"——它读的是 launch.json 里的一份配置。启动配置的本质，是把"怎么起 + 怎么挂调试器"固化成一项声明。

几个核心概念：

launch.json：调试启动的配置文件。每个"配置"描述一件事——以什么方式启动哪个程序、带什么命令行参数、环境变量是什么、要不要一启动就停在第一行、调试器连哪个端口。它是调试的"入口声明书"。
launch 模式：由 VS Code 直接把程序起起来，并自动把调试器挂上去。适合你从零启动一个程序来调试——你没在跑它，编辑器替你起、替你挂。
attach 模式：程序已经在跑（可能在容器里、在远程机器上、或者你手动起的），调试器只是"连上去"看它。适合你起不来、或程序必须由别的方式起的场景。
复合启动（compounds）：把多个配置合成一个。你点一下，前端和后端同时起、同时挂调试器，处在同一个调试会话里。

机制落点由此清晰：启动配置解决"调试入口可复用"——你不用每次手动拼启动命令、手动挂调试器，配置一次，以后一键。它站在前两讲能力之上：第12讲的 DAP 提供了"挂调试器"的底层能力，第13见的任务系统提供了"跑命令"的能力，而 launch.json 提供的是"怎么起 + 挂哪个 + 带什么环境"的声明。三者的关系像接力——任务系统负责"跑构建跑测试"，启动配置负责"起程序并挂调试"，DAP 负责"挂上之后能看能停"。可塑性在这里体现为：启动配置由你写、提交仓库，平台复用 DAP 把它变成可触发的入口——你配置一次，任何拉到这份配置的人都能一键调试，不需问老人"你到底怎么起的"。

要分清边界：启动配置解决"程序怎么被正确起起来并挂调试"，它不替你决定"该断在哪一行、该看哪个变量"——那是第12讲调试器本体的事。配置写错（路径不对、参数漏了），调试器再强也挂不上。它是"正确的起点"，不是"调试的全部"。

三、来龙去脉：从"手动起 + 手动 attach"到"配置即入口"

最早每次调试，流程是手工的：在终端把服务起起来、记下进程号或端口、切回编辑器手动 attach、祈祷断点命中。步骤多、易错、不可复现——你今天能调通，明天换台机器又得重新摸索一遍，团队里更是每人一套起法。

launch.json 的出现，把这套"起 + 挂"固化成声明式配置：你不再每次手工拼，而是把"以什么方式、起什么、带什么环境"写进文件。范式转折在于：调试入口从"每次手工拼"变成"声明式配置，且可共享"。这和第13讲 tasks.json 是同构的思路——把"怎么跑这个项目"从个人记忆变成仓库里的文件；和第2讲心智模型里"可配置、可扩展"的暗线完全咬合：VS Code 把"调试的入口"也做成了一个可配置、可沉淀的能力点。可塑性在这里兑现得最直接：你写一份配置，平台复用 DAP 执行，团队和未来的你都能复用这份入口——能力越大，越该让它"可被复用"，你才敢在不同的机器、不同的项目里放心调试。

四、破除误解：四个关于启动配置的错觉

误解一："launch.json 是高级玩家才配，我直接按 F5 就行。" 其实 F5 跑的就是 launch.json 里的一个配置——只是简单项目用默认配置能跑，你没意识到它在读配置。一旦项目"需要命令行参数、需要特定环境变量、需要多进程一起调"，不写配置根本起不对，F5 只会报错或起错程序。判断：凡"启动需要参数/环境变量/多进程"，必须写配置，别指望默认能跑。

误解二："launch 和 attach 差不多，随便选。" 完全两回事，选错就挂不上。launch 是"我来起程序并挂调试"——程序原本没跑，编辑器替你起；attach 是"程序已经在跑，我连上去"——比如它在容器里、在远程、或者由别的进程拉起。当你根本起不来那个程序（它在容器里），只能用 attach。判断：本地从零起用 launch；程序已在远端或容器里跑用 attach，别搞反。

误解三："复合启动是花活，开两个终端各自 F5 就行。" 当"前端 + 后端"要同时调试、且你想在它们两个之间共享同一个断点体验时，复合启动让它们处在同一个调试会话里、一个动作全起、一个动作全停。两个终端各自 F5，你得手动协调谁先谁后、哪个挂上了哪个没挂，常常顾此失彼。判断：凡"多进程要一起调"，用复合启动，别用两个终端手动协调——前者是一次编排，后者是反复对齐。

误解四："远程调试太麻烦，算了，加日志吧。" 其实 launch.json 配合远程开发扩展，能把"连远端进程"配置好一次，之后和本地一样一键触发。麻烦一次，省下的是无数次"加日志求人跑、等结果、再删日志"的来回。判断：程序在远端跑、本地复现不了时，第一反应是把远程调试配置进 launch.json，而不是退化到 print 调试——这和第12讲"能调试才敢改"是一以贯之的立场。

五、实践影响（重头戏）：把"怎么起、怎么挂、怎么验"沉淀成共享配置

下面按"配置—效率—工程—风险"四路给具体决策。

实践落点一：把"怎么起 + 挂调试"写进 launch.json，别每次手拼。 这是最基础的一招。场景：你每次调试都要在终端起服务、再手动 attach。把这套固化成一份配置，以后 F5 一步到位，断点必命中。判断：凡"调试前有一串准备动作"，写进配置，省的是每次的手工拼装和出错概率——可塑性在这里体现为：你把入口声明成文件，平台复用 DAP 执行，你只决定"起哪个"。

实践落点二：分清 launch 与 attach，按"程序谁起的"来选。 具体判断：程序由你从零起、本地能跑，用 launch；程序在容器里、在远程、或由别的进程拉起（你起不来），用 attach。选错模式是"断点不命中"的头号原因。判断：起不来就用 attach，起得来就用 launch——这一句能省掉大量"为什么我的断点灰了"的困惑。

实践落点三：用复合启动一键起多进程，统一调试会话。 场景：前后端联调，你想同时看请求从前端发出、到后端处理。在 launch.json 里定义一个 compound，把"前端配置"和"后端配置"合在一起，点一下两个都起、都挂、处在同一会话。判断：凡"多进程要一起调"，用复合启动，别开多个终端各自 F5——前者是一次编排，后者是反复对齐，体验天差地别。

实践落点四：把环境变量和启动参数固化进配置，消灭"我本地能跑你那边挂"。 很多"本地能跑、别人挂"的玄学，根源是启动参数、环境变量没固化，全靠每个人手动设。把这些写进 launch.json 的 env 和 args，谁拉到这份配置谁就有一致的起点。判断：凡"启动依赖特定环境/参数"，写进配置，别靠口头约定——这和第4讲"设置三层"是同一种治理直觉：把环境差异固化成文件，而不是依赖人的记忆。

实践落点五：团队共享一份 launch.json（接第12、13讲同构实践）。 新人入职最卡的不是写代码，是"项目到底怎么起、怎么挂调试"。把 launch.json 提交仓库，新人拉下来 F5 就能调，不用问老人"你那个服务是怎么起的"。这和第12讲共享 launch.json、第13讲共享 tasks.json 是同一条原则的三次落地：把"环境怎么起、怎么验证"从个人记忆变成仓库文件。判断：调试配置是团队资产，别只活在某人的本地。

实践落点六：用 preLaunchTask 把"先构建再调试"串起来（接第13讲桥）。 启动配置里有个关键字段 preLaunchTask——它指定"在起调试之前，先跑哪个任务"。于是你配成"preLaunchTask 跑构建"，每次 F5 先自动构建、构建过再挂调试。这是启动配置和任务系统的桥：任务系统负责"跑构建跑测试"（第13讲），启动配置负责"起程序挂调试"并能在起之前触发任务。判断：凡"调试前必须先构建/先迁移"，用 preLaunchTask 串，别手动先跑构建再 F5——这把两讲的能接力成一条自动链路。

实践落点七：把远程调试配置进 launch.json，和本地同体验（埋阶段六伏笔）。 程序常在容器或远程跑，本地复现不了。在 launch.json 里配好"连远端进程"的方式（配合远程开发扩展），之后和本地一样一键触发，断点、调用栈、变量全照常。这为阶段六"远程与容器开发"埋了伏笔——你能在本机界面里调试远端跑着的程序，体验不打折。判断：程序在远端跑、本地复现不了，第一反应是把远程调试配置进 launch.json，而不是退化到加日志——可塑性让远端调试和本地调试是同一次体验。

实践落点八：把"怎么起 + 怎么验"固化，收口 AI 验收闭环（呼应阶段四主线）。 回到本阶段的核心立场——"能验证才敢接受 AI"。你可以在 launch.json 里配一个带 preLaunchTask 的调试配置：起调试前先跑构建与单测任务（接第13讲），起起来后你针对 AI 改的关键路径设断点验证。这份配置一旦提交，不仅是你用，AI Agent 也能"按同一份配置把项目起起来验证"。判断：凡 AI 改了带逻辑的文件，用这份固化配置跑一遍（先构建再调再验），别裸读 diff——可控性在这里体现为：你用配置把"起 + 验"标准化，人和 AI 都按同一份契约走，AI 的产出成了可被同一流程验收的待审项，而不是各凭记忆的混乱。这正是对"能调试才敢改 AI 代码"在配置维度的收口，也是可塑性给你的集大成一击：启动配置把"调试入口"从个人手艺变成仓库里的契约。

六、承前启后：一句话记住

回到开头那个画面。你每次调试都要手动起服务、手动 attach，多进程联调更是手忙脚乱——根源不是你手慢，是**"怎么把程序起起来并挂上调试器"还活在每次的手工拼装里，没固化成一份配置**。launch.json 就是这份"调试入口的声明书"：它把"以什么方式起哪个程序、带什么环境、挂哪个调试器"写死成一项，F5 一步到位。launch 是"我来起并挂"，attach 是"程序已在跑、我连上去"——选错就断点不命中；复合启动把多进程合成一个动作、统一在同一个调试会话里；远程调试配置一次，和本地同体验。可塑性在这里兑现得最彻底：启动配置由你写、提交仓库，平台复用 DAP 执行，团队和 AI 都能按同一份契约起项目、验改动——能力越大，越该让它"可被复用"，你才敢在不同机器、不同项目里放心调试。

这一讲收官阶段四·调试与运行：第12讲把调试器变成你验证假设与审查 AI 的显微镜，第13讲把"跑构建跑测试"变成可复用可共享的任务，第14讲把"怎么起、怎么挂、怎么验"固化成启动配置——三讲串成一条线：能跑起来、能自动化跑、能一键正确跑并挂调试。下一讲我们进入阶段五·AI 集成，正面谈 Copilot：补全和 Chat 的边界、内联建议什么时候该信什么时候不该、以及"AI 产出越多，编辑器的验证与导航能力越是你杠杆"这条贯穿本系列的暗线如何落地。

能带走的一句话：launch.json 是调试入口的声明书——launch 我起并挂、attach 我连已跑的；复合启动一键起多进程、远程调试配置一次省无数次；把"怎么起怎么验"固化成配置，才敢放心让 AI 改、让新人接。