VS Code 使用笔记：新装机配置、插件取舍与效率习惯

VS Code 的好处是轻，麻烦也出在这个轻上：刚装好的它只是一个还不错的文本编辑器，顺不顺手取决于你往里填了什么、又克制住没填什么。网上流传的「完全指南」大多是功能清单的堆砌，照着抄一遍 settings.json，最后多半得到一台自己都不懂的编辑器。这篇笔记换个走法，按一台新机器从零开始的顺序来：先立住第一轮设置，再逐项讲 settings.json 里真正值得改的配置和背后的取舍，然后是插件怎么按语言与场景选、哪些高频操作值得练成习惯，最后是多设备同步与备份。已经用熟的人可以直接跳到插件一节，那里标了几个已经退役、不必再装的老面孔。

装好之后先做的事

第一件事是把命令行工具装上。macOS 在命令面板里执行一次 Shell Command: Install 'code' command in PATH，Windows 安装时勾选加入 PATH，Linux 用发行版包管理器装完自带。后面所有 code 命令的前提都在这一步，没装好的人经常卡在「终端里敲 code 没反应」这种小事上。

第二件事是登录账号、打开 Settings Sync（细节在文末同步一节）。顺序别反过来：先开同步再慢慢调配置，每一步调整都会被记下来，换机器时不用重来。

第三件事是字体和主题，这类纯口味设置早点定下来，省得日后每次打开都想换。编程字体建议选带连字的免费款：Fira Code 老牌稳妥，JetBrains Mono 字形偏窄、信息密度高，Cascadia Code 是微软自家出品、和 Windows 终端搭在一起最省事。装好字体后在设置里把 fontFamily 的第一顺位写它，再开 fontLigatures，连字看不惯随时关掉，不影响代码本身。

界面语言同理：需要中文界面就装官方的简体中文语言包，不需要就跳过，这件事没有任何「最佳实践」，只有自己看着顺不顺眼。

新装机最小配置清单

第一轮只需要把下面这几件立住，其余设置都等遇到具体问题再加：

• code 命令已进 PATH，终端里能用它打开当前目录
• Settings Sync 已打开并完成首次同步
• 一款编程字体已设为第一顺位，连字开关按个人口味定
• 自动保存与保存时格式化的组合已定下来（下一节讲两者怎么配合）
• 搜索与文件监视已排除 node_modules、dist 这类生成目录
• Git 的提交编辑器已设为 code --wait（命令行一节有写法）

对应的最小 settings.json 大致长这样，每项为什么值得进第一轮，下一节逐项说：

{
  "editor.fontFamily": "'JetBrains Mono', Consolas, monospace",
  "editor.fontLigatures": true,
  "files.autoSave": "afterDelay",
  "editor.formatOnSave": true,
  "editor.detectIndentation": true,
  "files.trimTrailingWhitespace": true,
  "files.insertFinalNewline": true,
  "editor.bracketPairColorization.enabled": true,
  "search.exclude": { "**/node_modules": true, "**/dist": true },
  "files.watcherExclude": { "**/node_modules/**": true, "**/.git/objects/**": true }
}

settings.json：关键项逐项讲

打开用户设置 JSON 用命令面板的 Open User Settings (JSON)。动手之前先分清三个作用域：用户设置只影响你自己；工作区设置存在项目根目录的 .vscode/settings.json 里，会跟着仓库走；还有跨编辑器通用的 .editorconfig。经验法则是：团队要统一的（缩进宽度、默认格式化器、排除目录）写进工作区设置并提交进 Git，纯个人口味（主题、字号、连字）留用户设置，谁也别替谁做主。如果团队里还有人用别的编辑器，缩进和行尾这类约定优先写 .editorconfig，它对所有编辑器都生效。

保存时格式化，前提是指定唯一的格式化器。 formatOnSave 打开之后，还要按语言用 [语言] 段指定 defaultFormatter，否则多个格式化插件会抢同一份活，出现保存后格式来回跳的现象。一个语言只留一个格式化器，这是后面插件取舍里最重要的一条纪律。配套的 formatOnPaste 和 formatOnType 则要谨慎：往项目里粘一段外部代码时被自动重排，对照原文找问题会很痛苦，多数人关掉粘贴格式化、用得到时手动执行格式化文档更稳妥。

自动保存选哪种，取决于你的工具链。 files.autoSave 设 afterDelay 最省心，写代码不用惦记保存。但如果项目里有监听文件变化自动重建、自动跑测试的工具，延迟保存可能把写了一半的代码送进构建，报出一串假错误。这种工作流下改用 onFocusChange——切走焦点才存，时机可控得多。

缩进别急着写死。 detectIndentation 打开时，编辑器会按每个文件现有的缩进风格走，打开老项目不会满屏别扭。新项目则相反：把 tabSize 定死写进工作区设置，全队一致。两种情况用两种策略，混着来最难受。

空白字符显示设 boundary 或干脆关掉。 设成 all 的人通常撑不过一周，满屏的圆点对阅读只有干扰。真正需要排查空白问题（比如混入了 Tab、行尾多了空格）时临时切换即可。倒是 trimTrailingWhitespace 和 insertFinalNewline 值得默认打开，能消掉 Git diff 里大量无意义的行尾改动；只提醒一句：老文件第一次打开保存会产生一大片「假改动」，最好单独成一个提交，别混进功能改动里。

括号着色是内置功能，不用装插件。 bracketPairColorization.enabled 打开就有彩虹括号和参考线（guides.bracketPairs），这件事后面还会再提一次，因为同名插件至今仍在被推荐。rulers 给 80、120 两列放个视觉参考就够了，它只是参考线，不是硬性规范，别拿它跟同事较真。

大项目卡顿，先查这三个排除项。 files.exclude 管资源管理器里藏不藏，search.exclude 管全局搜索进不进，files.watcherExclude 管文件监视听不听——三个环节互相独立，只配一个经常不够。node_modules、dist、.git 默认就该排除监视，这是大仓保持流畅最便宜的一步。至于 minimap，它对长文件定位确实有用，但占横向空间、也吃渲染，屏幕不大或项目偏大时可以关掉，用大纲视图加面包屑导航替代，定位能力并不差。

按语言指定格式化器的写法是这样，换成自己的技术栈即可：

{
  "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[python]": {
    "editor.defaultFormatter": "ms-python.black-formatter",
    "editor.codeActionsOnSave": { "source.organizeImports": "explicit" }
  }
}

命令行工作流

日常真正高频的就五六个，记熟比收藏一张大表有用：

code .                  # 打开当前目录（最常用）
code -r .               # 复用已有的窗口打开，不新开
code -n .               # 强制新开一个窗口
code -g app.ts:42:7     # 打开文件并跳到 42 行第 7 列
code --diff a.ts b.ts   # 并排对比两个文件
code --wait notes.md    # 等文件关掉后命令才返回
code --disable-extensions .  # 不带任何插件打开（排查问题时用）

两个容易记错的点单独说明。其一，-n 是新开窗口，不是「新建文件」，不少老笔记把这条写错。其二，--wait 的价值在给别的工具当编辑器：把 Git 的提交信息编辑器和终端的 EDITOR 都指向它，写提交信息时弹出熟悉的编辑器、关掉标签页才继续流程：

git config --global core.editor "code --wait"
export EDITOR="code --wait"

--disable-extensions 值得单独记：编辑器行为怪异或异常卡顿时，用它开一份干净实例，问题消失就基本可以断定是某个插件的锅，再回正常实例里二分禁用定位，比挨个猜快得多。

插件取舍

先立一条原则：别装太多插件

每个插件都是一个常驻进程，它会拖慢启动、占用内存、往右键菜单和快捷键里塞自己的东西，还可能和功能相近的插件互相打架——两个格式化器抢活、两个 Git 增强插件给出不一致的提示，都是从「先装上再说」开始的。装之前先过三条判断：一，它解决的问题我这周真的遇到了吗；二，这个功能是不是已经内置（括号着色、Emmet、Markdown 预览、基础 Git 操作全都是内置的）；三，装上之后我要不要为它维护配置。三条里有任何一条答不上来，就先收藏、不安装。

配套的两个习惯：语言支持只装官方或事实标准的扩展包，不用「全家桶」式的第三方合集；用 Profiles 功能给不同的技术栈建独立配置集，前端一套、写作用一套，比在一个配置里装齐所有语言的插件干净得多。用不上的插件先禁用观察一周，确认没影响再卸载，扩展面板偶尔翻一遍，三个月没碰过的都可以这样处理。

按场景选，而不是按榜单选

场景	值得装的	什么时候才需要它
前端	ESLint	项目本身在用 ESLint 做检查时，编辑器里实时提示才有意义
前端	Prettier	团队约定用它统一格式时；且要设为该语言唯一的默认格式化器
前端	Live Server	纯静态页面想快速起个预览服务时；项目有自己的 dev server 就用不上
Python	Python（含 Pylance）＋ Black Formatter	写 Python 的标配；语言服务和格式化被官方拆成两个扩展，分工如此
Go	Go 官方扩展	写 Go 时装，装完顺带让它把配套工具链装齐
远程	Remote - SSH	代码在服务器上、想在本地界面里改时
远程	Dev Containers	用容器做隔离开发环境时；它原名 Remote - Containers，已更名
Git	GitLens	经常要按行追溯作者、在编辑器里翻提交历史时；日常提交推送内置的源代码管理已经够用
写作	Code Spell Checker	英文文档和注释很多时；以中文为主的代码库里它只会添乱，按需
接口调试	REST Client 或 Thunder Client	前者把请求写成 .http 文件随项目走，后者图形界面顺手但部分高级功能已转付费，二选一即可

表里没有星级评分，因为评分说明不了任何事：一个插件值不值得装，只看它在你的工作流里解决什么问题、出现在什么时机。标签自动闭合、路径补全这类小功能同理，先确认内置的链接编辑（editor.linkedEditing，改开标签时自动改闭标签）够不够用，不够再找专门插件。

两个过时提醒

Bracket Pair Colorizer 已经退役。 它实现的功能从 2022 年的版本起就内置在编辑器里（就是前面说的 bracketPairColorization），插件本身已停止维护。还在各种推荐清单里看到它可以直接跳过，已经装了的卸掉、打开内置开关即可。

Remote - Containers 已经改名 Dev Containers。 老教程里的叫法和入口都按旧名字写的，找不到时按新名字搜。类似的还有 Python 的格式化：早期教程会让你在设置里指定格式化路径，现在的官方做法是装独立的 Black Formatter 扩展并设为默认格式化器，照老教程配容易配出一套已经不存在的选项。

快捷键与效率习惯

快捷键不用背全表，先把这十来个练熟，它们覆盖了日常九成的跳转和编辑动作：

功能	macOS	Windows / Linux	用在什么时候
命令面板	Cmd+Shift+P	Ctrl+Shift+P	任何「记得有这功能但忘了在哪」的时刻
快速打开文件	Cmd+P	Ctrl+P	按文件名找文件；再输 @ 跳符号、输 : 跳行
全局搜索	Cmd+Shift+F	Ctrl+Shift+F	跨文件找一处引用或一段文案
多光标添加匹配	Cmd+D	Ctrl+D	逐个选中相同的词一起改
选择全部匹配	Cmd+Shift+L	Ctrl+Shift+L	同上，但一次性全选，改前先确认数量
移动当前行	Alt+↑ / ↓	Alt+↑ / ↓	调整代码顺序，不用剪切粘贴
向上/下复制行	Shift+Alt+↑ / ↓	Shift+Alt+↑ / ↓	需要一份相近代码改几处时
重命名符号	F2	F2	改变量、函数、文件名，走语言服务
跳转到定义	F12	F12	看一个函数或组件的实现
返回上一位置	Ctrl+-	Alt+←	跳深了之后原路返回
切换集成终端	Ctrl+`	Ctrl+`	临时跑一条命令又回来

比背键位更重要的是三个习惯。第一，先练命令面板：记不住的快捷键都能在面板里搜到命令，旁边就标着键位，等于一边干活一边复习，这是学快捷键成本最低的路径。第二，重命名优先用 F2，它走语言服务，能分清同名的不同变量，只改真正引用到的地方；查找替换是纯文本层面的，留给字符串、注释和批量文案。第三，多光标只用在结构整齐的地方：给一组对齐的声明批量加前缀、改一组等长列表的尾巴，多光标又快又稳；结构参差不齐时硬凑光标，漏改错改的概率陡增，老老实实用下面的正则替换或者逐个处理。

正则查找替换：留几个真用得上的

VS Code 的查找框打开 .* 开关就是正则模式，替换框里用 $1、$2 引用查找里的分组，$0 指整体匹配，这是它和普通替换最大的区别。长长的转义字符表没有背的价值，真到了要写复杂表达式时，Regex101 和 RegExr 这类在线工具能一边写一边看匹配结果，调通了再粘回来。下面三个是日常真会反复用到的：

例 1：清掉所有行尾空白
查找：\s+$
替换：（留空）
其实也可以靠前面说的 trimTrailingWhitespace 在保存时自动做，手动版适合只清理某个目录的场合。

例 2：交换逗号两边的顺序
查找：(\w+),\s*(\w+)
替换：$2 $1
把 "Doe, John" 这类名单格式翻成 "John Doe"；推广开，分组编号就是干这个用的。

例 3：只保留中文字符
查找：[^\u4e00-\u9fa5]
替换：（留空）
清洗粘贴来的文本、提取中文文案时偶尔用；\u 区间表示汉字范围，这是它为数不多值得记住的写法。

两个安全提醒：全局正则替换前，先看一眼左下角的匹配总数并扫一遍高亮，是不是都是你以为的那些位置；范围上先限定到具体目录再动手。替换错了靠 Git 把文件捞回来，所以动手前先把当前状态提交一次，这一步比任何正则技巧都重要。

同步与备份

多台设备之间同步靠内置的 Settings Sync：登录 GitHub 或微软账号后在命令面板打开它，能同步的包括用户设置、快捷键、用户代码片段、界面状态和已装扩展的列表，换一台机器登录同一账号，等它同步完就能接着干活。它同步的是用户级配置，工作区设置本来就躺在仓库里，不走这条路。同步偶尔会遇到两台机器改了同一项的冲突，它保留了历史版本可以回看，真冲突了按时间挑一份即可，不用慌。

技术栈差异大的话，再配合 Profiles：给前端、后端、写作各建一个配置文件，各自有独立的设置和扩展集，从左下角齿轮或命令面板切换。这样既不用把所有语言的插件堆在一套配置里，也避免写作时被代码检查插件打扰——这正好呼应前面「别装太多」的那条原则，Profiles 是它在多场景下的落地方式。

Sync 之外建议再留一层手动备份，核心就是用户配置目录里的三样：settings.json、keybindings.json 和 snippets 文件夹。目录位置分别是 macOS 的 ~/Library/Application Support/Code/User、Windows 的 %APPDATA%\Code\User、Linux 的 ~/.config/Code/User，整个 User 目录拷走最省事。扩展清单单独导出一份文本，恢复时一条命令装回来：

# 导出已装扩展
code --list-extensions > extensions.txt
# 在新机器上批量恢复
cat extensions.txt | xargs -L 1 code --install-extension

把这几个文件顺手放进自己的 dotfiles 仓库，编辑器配置就和 shell 配置一样有了版本记录，哪天改崩了能回滚，这比任何云端同步都让人踏实。

变卡时的排查顺序

最后留一个收尾流程，因为插件装多、项目变大之后，卡顿迟早会来，排查有固定顺序，不用乱试：

1. 先看谁在拖后腿：命令面板执行 Developer: Show Running Extensions，能看到每个扩展的启动耗时和被唤醒的次数，常驻第一名往往就是元凶。
2. 再用 code --disable-extensions . 开一份干净实例对比：不卡了，问题在插件里，回到正常实例二分禁用定位；还卡，问题在项目规模或语言服务，先补齐 watcherExclude 和 search.exclude，再考虑关掉 minimap。
3. 语言服务在全仓建索引导致风扇狂转的，给它限定工作区范围或切到轻量模式，各语言扩展的做法不同，去它的设置项里找 workspace 相关开关。

编辑器配置是慢慢长出来的东西，一次配齐反而容易配错。按这篇的顺序走的好处是每一步都立刻能验证效果：设置改完保存一个文件就知道对不对，插件装完写一段代码就知道顺不顺手。觉得哪里别扭，回到对应小节调整，比推倒重抄一份别人的配置靠谱得多。