卡顿主因是prettier与eslint在onsave时并行触发形成隐式循环，叠加tsserver全量扫描、插件过早激活及扩展路径混乱；优化需解耦格式化与校验、限制tsserver范围、延迟加载插件、采用按需触发设计。
为什么装了 Prettier 和 ESLint 还会卡？
不是插件本身慢，是它们在 onSave 事件上同时抢着干活。VSCode 的保存钩子没有排队机制，两个插件都注册了 onSave，就会并行触发——Prettier 格式化完，ESLint 又扫一遍，再触发一次格式化（如果开了 eslint.format.enable），形成隐式循环。
常见现象包括：保存后光标卡住半秒、编辑器底部状态栏反复显示“Formatting…”“Validating…”、.vue 或 .ts 文件响应延迟明显。
- 禁用其中一个的保存时动作：比如只留
editor.formatOnSave+Prettier，关掉eslint.enable的自动修复（即不设"eslint.codeAction.onSave.fixAll": true） - 改用单点入口：在
.eslintrc.js中加"extends": ["prettier"]，再把defaultFormatter设为esbenp.prettier-vscode，让 ESLint 只做检查，Prettier 只做格式化 - 确认
eslint.validate不重复监听：避免同时写["javascript", "javascriptreact", "typescript", "typescriptreact"]，按项目实际用到的语言精简
TS/JS 语言服务卡顿，根本不在插件而在 tsserver
很多人以为是插件拖慢，其实 tsserver（TypeScript 语言服务器）才是大型项目里最耗资源的进程。它默认扫描整个 node_modules 和所有 import 路径，哪怕你只打开一个 utils.ts。
关键参数不是“开不开插件”，而是“让它看哪儿”。VSCode 内置的 TS 设置直接决定解析范围和内存占用。
- 必须关闭日志：
"typescript.tsserver.log": "off"（默认是"terse"，日志写入本身就很慢） - 禁用自动导入：
"javascript.suggest.autoImports": false和"typescript.preferences.includePackageJsonAutoImports": "off" - 限制项目根目录：
"typescript.preferences.allowIncompleteCompletions": false，配合"files.exclude"排除**/node_modules、**/dist等路径 - 超大项目务必启用 Project References：把单体项目拆成多个
tsconfig.json，让每个子项目只加载自己依赖的类型定义
扩展路径混乱导致启动慢，不是装得多，而是加载得早
VSCode 启动时会遍历 ~/.vscode/extensions（macOS/Linux）或 %USERPROFILE%\.vscode\extensions（Windows），对每个插件读取 package.json，检查 activationEvents。哪怕插件没被用到，只要它声明了 "*" 或 "onStartupFinished"，就会立刻激活。
典型“伪轻量”插件如 GitLens、Auto Rename Tag、Path Intellisense，启动即运行文件监视器或 DOM 扫描，CPU 占用飙升。
- 用命令
Developer: Show Running Extensions查真实负载，重点关注 “Activation Time (ms)” 和 “Memory (MB)” 列 - 手动控制激活时机：在
settings.json中加"extensions.experimental.affinity"，例如"ms-vsliveshare.vsliveshare": 2（数字越小越晚加载） - 删掉“永远用不到但自动启用”的插件：比如
Docker插件在非容器项目里毫无意义，却会在启动时拉起后台进程 - 不要用
--extensions-dir临时切路径来“测试”，这会导致 VSCode 无法复用缓存，反而更慢
JavaScript Booster 这类重构插件，为什么快且安全？
它不监听 onType 或 onSave，只响应用户主动点击的灯泡（CodeActionProvider）。也就是说：没点灯泡，它完全不运行；点了，才基于当前 AST 做局部分析——不扫描全文件，不重解析，不触发格式化链路。
这种设计规避了 90% 的插件性能陷阱，但代价是“不自动”。它适合对代码质量有明确诉求的场景，而不是靠“开着就省事”来换效率。
- 它依赖的是 VSCode 原生的
textDocument/codeActionLSP 请求，走的是编辑器最底层的响应通道，延迟低于 50ms - 所有转换逻辑都在客户端完成，不启子进程、不调外部 CLI、不读磁盘（除了当前打开的文档）
- 不兼容老旧 JS 语法：比如
var提升、with语句、arguments.callee，遇到就跳过，不会报错也不会卡死 - 若项目用了 Babel 插件自定义语法（如
babel-plugin-macros），它识别不了，此时灯泡压根不出现——这是有意为之，不是 bug
