根本原因是VSCode默认监听node_modules导致inotify句柄堆积，以及compression-webpack-plugin等插件在开发环境误写缓存至node_modules；需配置files.watcherExclude排除node_modules，并修正Webpack插件输出路径。
node_modules 体积持续增长，根本不是 npm install 的锅
你删了 node_modules、重装依赖后是正常的，但改几行代码再保存，它就涨 5MB——这说明问题不在依赖本身，而在构建或监听行为。VSCode 默认会递归监听整个工作区，node_modules 里动辄数万个小文件，每个都注册一个 inotify 句柄，这些句柄几乎不回收，内存和磁盘空间就 quietly 爬升。这不是“重复安装”，是 VSCode 在后台反复扫描、索引、甚至被某些插件（比如 ESLint、TypeScript Server）深度解析导致的副作用。
必须在项目级 .vscode/settings.json 中配 files.watcherExclude
files.watcherExclude 不是可选项，是底线配置。全局设置无效，不同项目依赖结构不同，只有项目根目录下的 .vscode/settings.json 才可靠。漏掉这一条，其他优化全白搭。
-
"**/node_modules/**": true—— 必须写，且带双星号和尾部斜杠，匹配所有子路径 -
"**/dist/**": true、"**/build/**": true、"**/.git/**": true—— 一并排除，防止搜索和监听扩散 - 如果用
pnpm，加"**/node_modules/.pnpm/**": true；用turborepo，加"**/.turbo/**": true -
search.exclude只影响 Ctrl+Shift+F 结果，不阻止监听器创建，不能替代files.watcherExclude
npm install 后体积又暴涨？检查有没有插件在写缓存到 node_modules
某些插件（尤其是自定义语言服务器、老旧的 TypeScript 插件、或带本地构建逻辑的扩展）会在 node_modules 下生成临时构建产物或缓存文件，比如 node_modules/.cache/ 或 node_modules/some-pkg/dist-temp/。这类行为不会出现在 package-lock.json 里，但会真实占用空间。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 运行
npkill或du -sh node_modules/** | sort -hr | head -20（macOS/Linux），看哪些子目录异常大 - 重点关注
.cache、dist、out、lib等命名的子目录，它们大概率是插件写的 - 禁用可疑插件后重启窗口（不是 reload），再对比
node_modules大小变化 - 若确认是某插件所为，查其文档是否有关闭缓存的配置项，或提 issue 要求支持
cacheDir指向项目外路径
Webpack 构建产物误写进 node_modules？压缩插件配置错了
compression-webpack-plugin 如果没配 assetNames 或 filename，默认可能把 gz 文件写到 node_modules 下的某个依赖包目录里——尤其当它被错误地应用在开发环境或 watch 模式下时。这种写入不会被 npm install 清理，只会越积越多。
- 检查
webpack.config.js中是否在dev或watch模式下启用了该插件 - 确认
filename配置指向的是dist/或build/这类输出目录，而非相对路径或空字符串 - 典型错误写法：
new CompressionPlugin({ filename: '[path][base].gz' })—— 这里的[path]可能展开成node_modules/some-pkg/lib/ - 安全写法：
new CompressionPlugin({ filename: 'assets/[name].[contenthash].gz' })，并确保output.path是干净的构建目录
真正麻烦的从来不是删不掉的文件，而是那些你没意识到正在悄悄写入的进程——它们藏在监听器、插件缓存、构建配置的缝隙里，等你发现时，node_modules 已经长成了一个你不敢轻易动的黑盒。
