禁用插件比调优更直接有效，80%以上大型项目卡顿源于扩展后台监听与激活；须优先禁用ESLint、Prettier、GitLens、Remote-SSH等宽泛activationEvents插件，推荐Workspace级禁用并用Developer: Startup Performance验证效果。
禁用插件比调优配置更直接有效——大型项目卡顿80%以上源于扩展在后台持续监听、扫描和激活，而非编辑器本身性能不足。
哪些插件必须优先禁用
不是所有启用的插件都该留着。真正拖慢大型项目的，是那些声明了宽泛 activationEvents 的扩展，比如含 "*"、"onStartupFinished" 或 "onLanguage:json" 的插件。它们会在 VSCode 启动时就加载，哪怕你当前只打开一个空文件夹。
- 重点排查：
ESLint（尤其未配.eslintignore时会全盘扫描）、Prettier（保存前预检触发 AST 解析）、GitLens（默认监听所有 Git 操作，包括.git/objects/中数万小文件） - 远程类插件如
Remote - SSH或Docker，即使没连接，也会预占进程和网络句柄 - 常驻解析型插件：
Auto Rename Tag、Path Intellisense、Bracket Pair Colorizer，它们在大型目录中持续构建 DOM 或符号树
禁用方式选 Workspace 还是 For All Folders
别一上来就卸载。禁用更安全，保留配置且可随时恢复；但选错范围等于白干。
-
Disable (Workspace)：仅对当前打开的文件夹生效，适合临时停用项目专属插件（比如某个 Vue 项目才用的Vetur） -
Disable (For All Folders)：全局禁用，适合长期不用的通用型插件（如Live Server、Color Highlight） - 右键插件 → 点击对应选项即可，无需重启 VSCode；但部分插件需重新打开文件或切换标签页才真正释放资源
如何验证禁用是否真起效
光看“不卡”不够，得用数据说话。VSCode 自带两个关键诊断命令：
- 运行
Developer: Startup Performance，重点关注 “Start Delay” 列 —— 数值 >100ms 的插件就是重点怀疑对象 - 运行
Developer: Show Running Extensions，对比禁用前后 “Load time” 和 “Activation time” 总和变化 - 终端执行
code --disable-extensions启动纯净版，如果明显变快，说明问题确实在扩展层 - 打开开发者工具（
Help → Toggle Developer Tools），切到 Console 标签页，观察是否有ENOSPC或watcher limit reached报错 —— 这是 inotify 句柄耗尽的典型信号
工作区级禁用才是团队协作的正确姿势
全局禁用会误伤其他项目。大型项目或跨技术栈团队必须用工作区级控制，否则 Python 插件在纯前端项目里照常启动，白白吃内存和 CPU。
- 在项目根目录
.vscode/settings.json中写死禁用项：{"extensions.disabled": ["ms-python.python", "bracket-pair-colorizer.bracket-pair-colorizer"]} - 配合
files.watcherExclude使用效果更稳，否则 GitLens 之类插件仍可能绕过禁用去监听.git/objects/ - 团队可通过版本控制提交该配置，确保所有成员环境一致，避免“在我机器上是好的”类问题
复杂点在于：很多插件（如 CodeGeeX）会忽略全局 "codegeex.enable": false，必须进 Plain Text 语言专属设置里再关一次；还有些插件（如 ESLint）即使禁用，若 eslint.options 未设 "ignorePath": ".eslintignore"，仍会递归扫描整个工作区。
