企业官网建设流程全解析

很多人用 VSCode 好几年，装了一堆扩展插件，等到要清理、换机器、或者排查某个插件引起的诡异问题（比如 CPU 飙升、代码提示错乱、终端卡顿）时，才发现打开扩展面板一个个找“卸载”按钮真的累人——尤其是那种装了几十个上百个扩展，甚至有些默认启用的又不开源又退不掉的扩展，更是让人头疼。其实 VSCode 的命令行终端里早就内置了一套跟扩展插件相关的管理命令，用法跟包管理器很像，能列出、启用、禁用、卸载、批量处理扩展，比用鼠标点 GUI 高效得多。这篇文章我不聊别的，专门把“Vscode 终端命令彻底卸载扩展 Extensions”这个事讲透，从命令原理、实际脚本、到中途踩过的坑和排查思路，一次性给全。本文内容适合所有用 VSCode 的开发者，不管你是刚入门的小白，还是天天敲命令行的老鸟，只要你想干净利落地接管自己编辑器里的插件，这篇就能直接照抄作业。

1. 内容整体设计与思路拆解

1.1 为什么要在终端里操作扩展卸载

先说个真实场景，我之前在一台工作机上装 VSCode 加插件，大概一百多个，其中有一批是早期尝鲜安装的，后来项目换技术栈基本用不上了。我当时想从插件面板里找到它们一个个卸载，来回切了好几个视图，还老是记不住到底哪些是用的、哪些是闲置的，最后干脆开了个终端，一条命令把所有扩展 ID 列出来，再写个脚本批量干掉不用的，一分钟全搞定。这就是终端命令最大的价值：可批量、可脚本化、可远程、可审计。

终端操作扩展还有一个好处，就是它不依赖图形界面。很多时候你是在远程服务器上用 VSCode（比如通过 SSH 连到开发机），或者在 WSL 环境里跑，图形面板虽然也能用，但响应速度明显比命令行慢，甚至会出现列表一直转圈、展示不全的问题。用命令直接管理扩展是纯 IO 操作，逻辑清晰、输出稳定。

1.2 核心思路：code CLI 命令结构

VSCode 安装完成之后，会在系统里注册一个code命令（Windows 上叫code.cmd，macOS/Linux 上一般叫code）。这个命令本质上就是 VSCode 可执行程序的门面，所有跟编辑器相关的操作都能通过它来做，包括打开文件、比较文件、安装扩展、列出扩展。扩展相关命令最常用的几个是：

• code --list-extensions：列出所有已安装的扩展 ID
• code --install-extension <extension-id>：安装指定扩展
• code --uninstall-extension <extension-id>：卸载指定扩展
• code --disable-extension <extension-id>：禁用指定扩展（不卸载）
• code --enable-extension <extension-id>：重新启用
• code --show-versions：展示扩展的版本详情

在动这些命令之前，你得先确认code命令在终端里是可用的。这一步虽然基础，但很多人真就卡在这。如果你在终端里敲code --version提示命令找不到，根本原因一般是安装时没勾选“加到 PATH”，或者 macOS 上装的是精简版没注册命令。解决办法很直接：Windows 上重新运行安装包，勾选“添加至 PATH”；macOS 上打开命令面板输入Shell Command: Install 'code' command in PATH，执行完重开终端就生效了。

这个命令模型本身是在“用户级”还是“系统级”操作的？VSCode 的扩展分为用户扩展和工作区扩展，命令行工具默认操作的是用户配置目录下的全局扩展列表。对于大部分开发者来说，日常装的扩展都挂在用户级，所以命令用起来很顺手，无需额外指定。

1.3 方案选型的原理解读

如果你用过 npm、pip 或者 apt 这类包管理器，再看code --install-extension这类命令会觉得特别亲切。VSCode 的扩展市场本质上也是一个远程仓库，扩展 ID 都是publisher.name格式，比如esbenp.prettier-vscode。命令行安装扩展时，它内部会走扩展市场的协议，下载对应插件包，解压到用户目录下的.vscode/extensions文件夹里，然后更新扩展列表缓存。

卸载的过程则相反：把插件目录删掉，并从缓存列表里移除。所以你会发现一个现象：有时候终端卸载报成功，但插件面板里还残留显示，重启 VSCode 之后才会消失。别慌，下面第 4 章我会专门讲这个问题的排查思路。这里先把命令搞懂，后面就顺了。

2. 核心细节解析与实操要点

2.1 查看当前已安装的扩展清单

想卸载扩展，第一步永远是“看清楚自己装了什么”。这里的推荐命令不是--list-extensions --show-versions直接用，我建议先做一步分类：

code --list-extensions

它输出的每一行是一个扩展的 ID，比如：

ms-python.python esbenp.prettier-vscode github.copilot dbaeumer.vscode-eslint

如果只输出 ID 不够，你想附带知道每个扩展的版本和是否有更新？可以加参数：

code --list-extensions --show-versions

这个命令会输出类似：

ms-python.python@2024.4.0 esbenp.prettier-vscode@10.4.0 github.copilot@1.5.2

这种带版本号的信息在排查问题时很实用，比如某个扩展最新版有兼容问题，你想回退，就先得知道当前装的是什么版本。

你还可以在列表导出时顺手做一下数量统计（Windows PowerShell 和 macOS/Linux 语法略不同，但思路一样）：

code --list-extensions | wc -l

这个数字能让你对自己的“插件密度”有个直观认知。我用过的机器里，有的开发机插件数超过 120 个，其中真正每天都用得上的可能就 20 个左右，其余全是历史遗留。这种情况下，先在终端里跑一遍导出，再把列表按“当前项目需要”和“可清理”两组分类，比在 GUI 里挨个翻要高效得多。

2.2 卸载单个扩展的准确姿势

卸载单个扩展的命令语法非常简单：

code --uninstall-extension <extension-id>

比如卸载 Python 扩展：

code --uninstall-extension ms-python.python

执行完，终端会输出一行提示（不同版本略有差异）：

Extension 'ms-python.python' is uninstalled.

如果你在卸载的时候忘了扩展的完整 ID，只记得名字里带“python”，可以先用--list-extensions配合 grep 过滤一下。

macOS/Linux：

code --list-extensions | grep python

Windows PowerShell：

code --list-extensions | Select-String python

这里有个细微但很关键的细节：--uninstall-extension后面的扩展 ID 必须严格匹配列表里的 ID，大小写、点号都不能错，否则终端会报错或者找不到目标。如果你想把卸载过程显式化，可以先执行--list-extensions，把输出丢到一个文本文件里，然后从文件里精确复制你要卸载的 ID。这样能避免手滑敲错。

注意：如果当前 VSCode 正在运行，且你要卸载的扩展正在被使用（比如正在用某个语言服务扩展编辑文件），终端里卸载基本能完成，但建议还是先保存好未保存的文件再操作，以免扩展崩溃导致内容丢失。我在实测中遇到过几次，卸载正在使用的扩展后，编辑器里某个语言服务报了错误，重启编辑器才好。

2.3 命令行禁用和启用扩展：比卸载更灵活的方案

有些扩展不是你完全不用，而是“暂时不用”或者“疑似有问题需要隔离验证”。这时候不要急着卸载，用禁用更稳。禁用扩展不会删除文件，只是在启动时不让它加载，遇到问题想再恢复很容易。

禁用单个扩展：

code --disable-extension <extension-id>

而且 VSCode 还支持直接禁用所有扩展进入“干净模式”，排查问题时特别常用：

code --disable-extensions

这个命令会启动一个新的编辑器窗口，所有扩展都不加载。如果你发现这个窗口里编辑器不再卡顿、报错消失，那基本可以断定问题是某个扩展引起的。

再恢复启用单个扩展：

code --enable-extension <extension-id>

这个模式最大的价值在于，它让你能够二分法排查：禁用所有扩展，如果问题消失，再分批次启用扩展、逐个隔离问题源。这个思路我们在第 4 章还会再展开。

2.4 卸载之前，必须注意的扩展关联问题

VSCode 的扩展不像独立软件那样跟系统有千丝万缕的依赖，但它会涉及几个隐蔽关联点，清理前你得心里有数：

• 工作区级配置引用：如果你在.vscode/settings.json或settings.json里写了某个扩展的配置项（比如"editor.defaultFormatter": "esbenp.prettier-vscode"），卸载扩展后，这个配置项就会变成无效键。VSCode 在打开工作区时会提示“未知配置项”，虽然不影响开发，但从此打开项目就多了一道“警告横幅”，看着很碍眼。
• 键盘快捷键：有些快捷键绑定是扩展提供的（比如 Python 扩展的jupyter相关组合键），卸载后快捷键会消失，如果你的肌肉记忆还按原来的组合键，会发现没响应，这时候需要在快捷键面板检查哪些绑定键是未定义状态。
• 代码片段（Snippets）：如果你使用过某些扩展提供的代码片段，卸载之后这些片段就不再可用，但你自己定义的 snippet 文件保留在用户目录，不受影响。
• 共享语言服务：有些扩展之间互相依赖，比如你卸载了某个 LSP 客户端扩展，但另一个扩展还依赖于它启动的语言服务器，结果就是另一个扩展的某些功能失效但不报错。

所以我的建议是，卸载之前先搜一下当前项目根目录下的.vscode/settings.json，以及用户级settings.json，凡是涉及你准备卸载的扩展的配置项，提前清理或改掉。不然卸载完，VSCode 会一直给你提示“Don't show again”的选项，你要是眼不见为净点了忽略，后面排查问题又会少一条线索。

3. 实操过程与核心环节实现

3.1 单条命令完成“查找和删除命令”全过程

现在进入实战。假设我要卸载一个叫old-theme-extension的插件，但我记不清完整 ID 了。完整流程如下：

第一步，打开终端（Windows 下可以用 PowerShell 或 CMD，macOS 用 Terminal 或 iTerm2），确认code命令可用：

code --version

输出类似：

1.85.0 ...

第二步，列出所有扩展，并过滤出关键词：

code --list-extensions | grep old-theme

如果输出：

mytheme.old-theme-extension

第三步，精确卸载：

code --uninstall-extension mytheme.old-theme-extension

输出：

Extension 'mytheme.old-theme-extension' is uninstalled.

第四步，重新列一次，确认卸载干净：

code --list-extensions | grep mytheme

无输出，说明列表中已不存在该扩展。

整个过程不超过 20 秒。如果你是在远程开发机上操作，用 SSH 终端执行完全一样的命令也是可行的，VSCode 的命令行扩展管理接口在不同环境下表现一致，这一点在团队协作、统一开发机环境时特别管用。

3.2 批量导出、批量卸载的脚本方案

单条卸载适合点对点清理，但如果你像我之前那样，需要一次清掉二三十个不用的扩展，一个个敲命令就有点傻了。下面这个思路你可以参考。

首先，把当前完整的扩展列表导出到文件：

code --list-extensions > installed-extensions.txt

然后，用文本编辑器打开这个文件，把你想保留的扩展留下，其他行删除，另存为keep.txt。

接着，在终端里用循环语句对比两个列表，把不在保留列表里的扩展全部卸载。

macOS/Linux 下用 Bash：

while read ext; do if ! grep -q "^${ext}$" keep.txt; then code --uninstall-extension "$ext" fi done < installed-extensions.txt

Windows PowerShell 下则这样写：

$extensions = Get-Content installed-extensions.txt $keep = Get-Content keep.txt foreach ($ext in $extensions) { if ($keep -notcontains $ext) { code --uninstall-extension $ext } }

这段脚本的思路很简单：全量列表减去保留列表，剩下的就是待清理列表。执行之后终端会逐条打印卸载结果，你就能看到哪些成功了。如果某条报错“Extension is not installed”，大概率是扩展 ID 里带了空格或者不可见字符，检查一下文件编码和换行符就好。

批量安装也是一样的套路，把扩展 ID 一行一个放进文件，然后：

while read ext; do code --install-extension "$ext" done < extensions-list.txt

这个方式在换新电脑时尤其有用，先在新机器上导出旧机器的扩展清单，再批量安装，基本能无缝恢复你的开发环境。我自己的做法是把常用扩展清单按项目类型维护成多个文件，比如web-dev.txt、python-dev.txt、deeplearning.txt，需要哪个环境就批量装哪个，插件治理非常清晰。

3.3 用扩展 ID 精确清理 VSIX 安装的扩展

还有一种情况是扩展不是从市场装的，而是通过.vsix文件离线安装的，比如公司内网环境、或者一个尚未公开发布的内部插件。这类扩展用code --list-extensions也能看到，卸载方式跟市场扩展完全一样，仍然用扩展 ID 卸载。比如：

code --uninstall-extension company.internal-tool

如果你压根不知道它的 ID 是什么，可以到用户扩展目录里看一下具体文件夹名，文件夹的命名格式通常是publisher.extension-name-version，其中publisher.extension-name就是扩展 ID。

macOS 上扩展目录一般是：

~/.vscode/extensions/

Windows 上一般是：

%USERPROFILE%\.vscode\extensions\

Linux 上对应：

~/.vscode/extensions/

直接删目录确实也能达到“卸载”的效果，但我不推荐手动删，因为扩展目录里还可能包含.obsolete等标记文件，手动删不干净的话，VSCode 启动时会尝试根据记录重新加载，导致各种玄学问题。用code --uninstall-extension会同步处理这些状态，干净又安全。

3.4 验证清理成果与配置残留检查

卸载完一波扩展后，别急着关终端，推荐按下面三步确认清理效果：

第一步，确认扩展列表里已经没那些 ID：

code --list-extensions

第二步，检查扩展目录中的实际残留：

macOS/Linux：

ls ~/.vscode/extensions/ | grep <关键词>

Windows PowerShell：

Get-ChildItem $env:USERPROFILE\.vscode\extensions | Where-Object { $_.Name -match "<关键词>" }

如果输出为空，基本说明目录层也已清理干净。如果有残留目录，多半是卸载过程不正常（比如 VSCode 还在运行、文件被占用），需要关闭所有相关进程后手动删除。

第三步，打开 VSCode 设置面板（快捷键Ctrl+,/Cmd+,），在搜索框里搜卸载掉的扩展名，看是否还有残留配置项。如果有，手动删掉对应键值。这里尤其要注意.vscode/settings.json和settings.json里的配置。你不删，编辑器也能运行，但会在“设置”副标题里一直给你标黄提示，很影响观感。

4. 常见问题与排查技巧实录

4.1 命令提示“command not found”或“不是内部或外部命令”

这是新手最容易卡住的一步。如果终端提示找不到code命令，一般有三种原因：一是安装时没加入 PATH，二是 shell 缓存没刷新，三是用的安装版本没有命令行工具。

解决办法（按优先顺序）：

• Windows：重新运行 VSCode 安装包，在选择组件的步骤中，勾选“添加到 PATH”选项，完成后重启终端。
• macOS：打开 VSCode 命令面板（Cmd+Shift+P），输入Shell Command: Install 'code' command in PATH并执行，之后重开终端。
• Linux：确认安装包是否来自官网仓库，如果用了 Snap 版的 VSCode，有时code命令会被封装成code的路径问题，可以用/snap/bin/code或者重启整个终端环境解决。
• 所有平台：试着重开终端。如果 zsh 或者 bash 的hash缓存里没有更新，确实会偶发找不到命令的情况。

我给个小技巧：你在终端里可以先执行which code（Windows 用where code），如果输出一个路径，说明命令本身就存在，问题可能是 PATH 顺序或者 shell 缓存；如果没有任何输出，那就按上面三种原因逐个排查。

4.2 卸载后扩展还出现在列表里，怎么办

我在实际使用中遇到过这种现象：跑完code --uninstall-extension，命令也提示成功，但再次执行code --list-extensions，这个扩展还在列表里。折腾过几次之后，我总结出来的原因主要是这两类：

第一，VSCode 处于运行状态。命令行工具在修改扩展列表时，如果编辑器进程正在运行，可能会因为文件占用或者缓存机制导致删除不彻底。解决办法是关掉所有 VSCode 窗口后，再重新执行卸载命令。

第二，扩展同时存在于多个层级。VSCode 支持用户级、工作区级和内置扩展，其中内置扩展无法卸载（比如vscode.typescript-language-features这类），工作区级扩展配置在某些场景下也会重新拉取依赖。你用命令行卸载的是用户级条目，但工作区里通过.vscode/extensions.json推荐的扩展可能会在重启后重新提示安装。

如果确认不是上面两种情况，还有最后的大招：直接去扩展目录删文件夹，同时清理~/.vscode/extensions/.obsolete文件里对应的行。操作前记得关掉 VSCode。删完再启动编辑器，去看扩展面板还显不显示。

其实严格来说，不属于内置扩展的情况下，用命令行卸载之后那个扩展还出现在列表里，多数情况是编辑器没重启，界面缓存没更新。重新加载窗口（开发人员工具里有 reload window）往往就能解决。

4.3 批量脚本执行到一半卡住，如何继续跑完

批量卸载跑循环时，偶尔会遇到某一条命令在下载或解析插件信息时卡住。尤其是扩展数量多、网络状况一般的情况下，终端会等一段时间才输出结果。遇到这种别直接Ctrl+C全停，更稳妥的做法是：

• 给命令加超时逻辑，比如 macOS/Linux 用timeout 30 code --uninstall-extension "$ext"（需要安装了 coreutils），超时会自动跳过这一条。
• 或者先暂停整个脚本，手动执行这一条出问题的卸载，确认它到底是在等网络还是在等锁。然后用记录文件标记成功和失败的分界点，跳过已成功的继续跑。

我用 PowerShell 批量处理时，习惯在脚本里加个“继续执行不中断”的-ErrorAction Continue逻辑（具体写法按你的 PowerShell 版本微调），这样即使个别扩展卸载报错，也不会中断整批清理。重点不是一次性全成功，而是最后能看到一份“哪些成功、哪些失败”的清单，针对失败的再人工处理，效率和成功率反而更高。

4.4 卸载某些扩展后编辑器功能异常，怎么恢复

卸载完后发现某个功能没了，这种情况在开发环境中太常见了。比如我卸载了某个“花里胡哨”的主题扩展，结果发现代码高亮风格变了——这是正常的，因为高亮回退到了默认配色。但如果你发现的是更实质性的问题，比如格式化代码不起效、代码跳转失灵、调试器按钮灰掉，那就需要仔细排查了。

排查思路很简单：

1. 先在终端执行code --list-extensions，确认你是不是真的把某个功能依赖的扩展卸了。比如你把 ESLint 卸了，代码里那些红色的校验波浪线自然就没了，这不是 VSCode 出 bug，是你把校验器干掉了。
2. 回忆一下自己刚卸了哪些扩展，挨个查一下有没有替代方案。有些扩展卸载后，它的某些能力会被内置功能接管，但不会完全一致。比如卸载了某个括号高亮扩展，编辑器还是会显示基础括号匹配，只是没之前那么炫。
3. 要是实在找不回当时的功能，就重新把扩展装回来。批量安装非常快，一条code --install-extension就搞定，安装完重载窗口即可。

这里我还想多说一句：卸载扩展之所以容易“误伤”功能，核心原因是很多扩展之间是存在传递依赖的。比如你装了某个框架的语言服务器扩展，它内部可能自动帮你装了另一个格式化扩展，但你只卸载了表面那个，格式化扩展可能还停在那里。所以不要只盯着自己要卸载的那一个，多看一下 VSCode 的输出面板中的扩展日志，了解清楚依赖关系再动手。

4.5 实测整理的扩展命令速查表

下面这张表是我在使用过程中整理的，直接保存在笔记里，每次批量清理扩展前都会扫一眼：

这个速查表其实已经把 VSCode 扩展管理 90% 的日常需求覆盖了。剩下那 10% 是 GUI 上的一些特殊管理功能（比如更新、降级、按来源筛选），但说实话，在终端里通过切换扩展 ID 的方式完全能做到同样的效果，只是命令步骤多一点。

5. 实战案例：一次完整的扩展清理与一键恢复

5.1 先用命令给编辑器来一次“全量体检”

上个月我想给公司一台老开发机“瘦身”，那台机器从三年前开始用 VSCode，中间换过几轮项目方向，从 Node.js 写到 Java 后端又写过一段物联网的嵌入式代码，后来还尝试过一阵 Python 数据分析。插件越积越多，最直观的表现是打开编辑器要 10 秒以上，操作偶尔觉得画面掉帧。我当时心里清楚，大概率是某些常驻扩展拖累了性能。

于是我先在终端里导出了问题源的候选名单：

code --list-extensions --show-versions > all-ext.txt

看到输出的 87 个扩展，我心里大概有了数。紧接着我用下面的命令看每个扩展的占用情况（这一步需要在编辑器内部配合，否则只看命令导出结果很难判断谁占资源多）：

打开 VSCode 的“开发者进程面板”（快捷键Ctrl+Shift+U可以看到输出，进程管理在命令行面板→Developer: Show Running Extensions），这个面板会列出每个扩展的激活时间和占用的进程 ID，是定位性能问题最直接的证据。

结合这份数据和项目实际需求，我整理出了 30 多个不再使用的扩展，记录在一个清理清单里。

5.2 批量卸载加验证，一次搞定

按上面第 3.2 节的脚本思路，我把待清理清单存进文件，然后跑循环卸载。中途有几条因为网络原因卡了几秒，但都顺利执行完。卸载结束后，我再次执行：

code --list-extensions

列表从 87 个降到了 52 个。随后我检查了一下扩展目录，确认没有多余残留：

ls ~/.vscode/extensions/ | wc -l

数量上比扩展列表多几个，是因为有少量扩展在目录里留下了一些配置文件，但属于正常现象（比如代码片段和全局 storage）。我重启了编辑器，启动速度确实快了不少。

5.3 另一台机器秒级恢复环境

那台机器清理完之后，我顺手把保留的扩展列表导出到仓库里维护：

code --list-extensions > ./extensions/essential.txt

后来入职了一个新同事，我直接把这份清单发给他，他在自己机器上执行：

while read ext; do code --install-extension "$ext" done < essential.txt

十分钟不到，他本地的 VSCode 就跟团队环境基本对齐了。这也是命令行管理扩展最好的一个附带收益：环境标准化、可复制、可审计。比起让每个人按照 PPT 截图里的插件名搜了装、装了配，效率提升不是一个量级。

6. 个人实操体会与一个补充小技巧

我自己的习惯是每两个月左右跑一次扩展清单，对照最近的工作内容删掉不用的扩展。这个事靠 GUI 手动做确实比较烦，但用code命令以后基本零负担：导个清单，写个循环，再验证一下，全程不超过五分钟。VSCode 的扩展管理命令其实远比大多数人以为的要成熟，--list-extensions、--install-extension、--uninstall-extension这几个核心命令已经能覆盖日常百分之九十的插件管理需求，剩下的部分靠组合脚本和速查表也能轻松补齐。

最后再分享一个小技巧：如果你要在一台新电脑上完整复刻旧机器的扩展环境，除了导出扩展 ID 清单，我还建议你把用户级别的settings.json和keybindings.json也一起备份起来。扩展只是工具的一部分，真正的个性化配置才是你回不去旧手感的原因。把这些文件存进自己的配置仓库，配合code命令的批量安装，换机器、重装系统、加入新团队都能做到“无缝搬家”。这套流程我现在已经跑通很多次了，实测非常稳。