vscode启动慢主因是npm install后默认监听node_modules及ts/eslint全量扫描；需配置files.watcherexclude、禁用typescript.preferences.includepackagejsonautoimports为"off"、挪走全局npm路径并禁用冗余语言功能。
为什么 npm install 后 VSCode 启动还是慢？
不是 Node.js 慢，也不是你装了太多依赖——真正拖慢的是 VSCode 在启动时对 node_modules 的默认监听 + 语言服务器（如 TypeScript、ESLint）的全量扫描。哪怕你只写个纯 JS 脚本，tsserver 仍会尝试解析整个 node_modules/@types 和项目中所有 .js 文件，尤其当 node_modules 有上万文件时，CPU 占用飙升、编辑器卡顿几秒是常态。
关键点在于：VSCode 不区分“是否真要用到”，只要目录存在，就默认纳入索引范围；而 npm install 后首次打开项目，正是触发最重的一次全量扫描。
-
files.watcherExclude必须生效，否则 chokidar 会持续监听node_modules下每个文件变更，耗尽 inotify 句柄（Linux/macOS）或触发 Windows FindFirstChangeNotification 阻塞 - 仅靠
search.exclude不够——它只影响搜索，不影响语言服务初始化和符号索引 - TypeScript 语言服务器默认启用
semantic模式，会加载并分析所有可达模块；对非 TS 项目，这纯属冗余开销
typescript.preferences.includePackageJsonAutoImports 怎么设才不拖慢？
这个配置控制 TS/JS 语言服务是否自动从 package.json 的 dependencies 中推导类型导入路径。设为 "auto" 或 "on" 时，VSCode 会扫描整个 node_modules 查找匹配的 @types/* 包，并尝试预加载它们的声明文件——这是冷启动卡顿的隐形主力之一。
多数纯 Node.js 项目根本不需要自动导入类型，尤其用 require() 或 ESM 动态 import() 的场景。
- 推荐设为
"off"：彻底禁用自动类型导入推导，语言服务启动快 30%+（实测中型项目从 4.2s → 2.8s） - 若需部分支持（比如只对
express、lodash等常用包补全），可改用"minimal"，但需配合typeAcquisition显式白名单 - 别在全局 settings.json 里设——不同项目需求不同，应写进项目级
.vscode/settings.json
VSCode 冷启动时要不要等 tsserver 预编译？
不需要，而且不该等。VSCode 的 tsserver 本质是 TypeScript 编译器的后台服务，所谓“预编译”只是它在内存中构建 AST 和类型图的过程，并不生成真实文件。这个过程发生在编辑器空闲时，但首次启动时它会抢占主线程资源，导致 UI 响应延迟。
更糟的是：如果你没开 save without formatting 或禁用保存时 ESLint 自动修复，tsserver 还要和 ESLint 插件争抢文件句柄，进一步放大卡顿。
- 关掉
typescript.preferences.autoImportFileSuggestions：避免补全弹窗触发额外类型解析 - 把
eslint.run设为"onType"而非"onSave"，让校验异步化，不阻塞保存操作 - 对纯 Node.js CLI 工具类项目，直接禁用 TypeScript 语言功能：
"typescript.suggest.enabled": false，VSCode 会跳过加载tsserver
Node.js 全局模块路径不改，VSCode 就永远慢一半
默认 npm install -g 把命令行工具装进 %APPDATA%\Roaming\npm（Windows）或 ~/Library/npm（macOS），这些路径常被杀毒软件、OneDrive 或 Time Machine 实时监控。VSCode 启动时若检测到全局 bin 目录下有大量可执行文件（比如 serve、json-server、nodemon），会尝试读取其 package.json 并建立符号链接缓存——这个动作在受监控目录下极慢。
这不是 VSCode 的 bug，是它对“可用命令”的主动发现机制在作祟。
- 必须执行
npm config set prefix和npm config set cache指向非系统监控路径（如D:\dev\nodejs\node_global） - 修改后记得清理旧全局安装：
npm ls -g --depth=0→ 手动删掉%APPDATA%\Roaming\npm下残留文件夹 - 重启 VSCode，再运行
Developer: Startup Performance，观察 “Global npm modules scan” 阶段耗时是否归零
真正卡住你的，从来不是代码量，而是那些没人告诉你“该关”的后台扫描和默认推断逻辑。一旦排除 node_modules、锁死语言服务模式、挪走全局模块路径，VSCode 启动就不再是等待，而是即时响应。
