核心在于精准管理扩展启停：先按禁用状态筛选闲置扩展，再查Contributions确认是否真被使用；禁用仅停用功能，卸载才释放资源，Deprecated、功能重复、频繁报错或Node版本过低者应卸载；推荐按工作区隔离启用，并关闭自动更新以提升性能。
VS Code 扩展太多，不是卡顿就是功能冲突——核心问题不在数量，而在「哪些该启用、哪些该禁用、哪些根本不需要」。
怎么快速识别没用的扩展
很多扩展装完就闲置，比如只在某次项目里临时需要的 ESLint 配置工具、GraphQL 语言支持，或早已被内置替代的旧版 Auto Close Tag。VS Code 本身不记录使用频率，但你可以靠三步筛掉一半：
- 打开扩展视图（
Ctrl+Shift+X或Cmd+Shift+X），点击右上角「已安装」筛选器 - 按「禁用」排序，把状态为「Disabled」且最近没手动启用过的扩展先选中
- 看扩展详情页的「Contributions」标签：如果它只注册了某个冷门命令（如
extension.sortLines）但你从没调用过，大概率可卸载
禁用 vs 卸载：什么情况下必须卸载
禁用只是停用功能，扩展文件仍驻留在磁盘并参与启动扫描；卸载才真正释放资源。以下情况建议直接卸载：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 扩展已明确标注「Deprecated」或作者主页写明「replaced by
xxx」 - 同类型功能重复：比如同时装了
Prettier和Beautify，又只用其中一种格式化 - 触发过
Extension host terminated unexpectedly错误，且重装后仍频繁报错 - 扩展依赖的 Node.js 版本明显低于当前 VS Code 内置版本（查看其
package.json中的engines.vscode字段）
按工作区隔离扩展启用状态
不必全局开关——VS Code 支持为每个文件夹单独控制扩展。适合前端项目用 Vetur、Python 项目用 Pylance 的场景：
- 打开项目文件夹后，在扩展视图中找到目标扩展，点击右下角齿轮图标 → 「Disable (Workspace)」
- 此时该扩展在其他文件夹仍可用，但当前项目完全不加载
- 注意：
settings.json中会多出一条"extensions.ignoreRecommendations": true类配置，别误删 - 推荐搭配
Settings Sync使用，避免不同机器间工作区设置错乱
为什么有些扩展禁用后 VS Code 还很慢
禁用扩展 ≠ 立即释放内存。VS Code 启动时仍会读取所有已安装扩展的 package.json 并解析贡献点（commands、keybindings、languages 等）。真正影响启动速度的是「激活事件」（activationEvents）配置不当的扩展：
- 比如一个只处理 Markdown 的扩展，却声明了
"*"或"onStartupFinished"，它会在每次启动时被加载 - 用
Developer: Show Running Extensions命令查看实际加载的扩展列表，重点关注「Activation Time」列数值高的 - 这类问题无法靠用户端修复，只能反馈给扩展作者或换用更轻量的替代品（例如用
Markdown All in One替代多个零散 Markdown 工具）
最常被忽略的一点：扩展更新机制本身会悄悄拖慢后台。开启 "extensions.autoUpdate": false 后，手动检查更新前不会触发静默下载，尤其对网络受限或 SSD 容量紧张的环境很关键。
