如何在VSCode中清理Node环境缓存

在VSCode里折腾“Node环境缓存清理”，这事儿听起来很常见，但实际操作中，很多人其实跑偏了。我先给你个准话：VSCode本身根本就不管理什么Node.js环境缓存。你所谓的“Node环境缓存”，实际上是三类独立于VSCode之外的残留：系统级的Node.js安装目录、全局npm命令的存放路径、以及某些插件为了跑语言服务自己偷偷缓存的node_modules和二进制文件。如果你清理了错的位置，不仅解决不了问题，还可能导致调试断点失灵、语言服务器启动报错——结果更糟。

先说说最常见的误区：删VSCode的Cache目录，纯属无用功。在Windows上，那个%APPDATA%\Code\Cache（macOS或Linux是~/.cache/Code），只存放Chromium渲染层的资源，比如Marketplace页面的快照、Markdown预览的缓存。它跟Node.js的执行逻辑、ts-node的转译结果、node_modules的内容没有任何关系。你把这里清了，node -v该是多少还是多少，npm install照常运行——最多就是VSCode的UI会有短暂卡顿，因为它得重新下载渲染资源。所以，别再跟这个目录较劲了。

• 真正能影响Node运行的，是node_modules/.cache（这是esbuild、vite、jest用的）、%APPDATA%\Roaming\npm（全局CLI工具的老巢）、以及~/.vscode/extensions下那些插件自己留下的私有缓存目录。
• 有时候你删了Cache目录之后，发现“Python语言服务器起不来了”，其实问题根本不在那——是你漏掉了extensions下面带-cache后缀的那个文件夹。
• 如果终端里node -v仍然返回旧版本，那一定是系统PATH环境变量或者where node指向的路径有问题，跟VSCode缓存半毛钱关系没有。

必须手动清理的四个Node相关路径（Windows）

真正需要动手的，是下面这四个Windows路径。很多时候，就算你用控制面板卸载了Node.js，这些地方依然会有残留，而且它们直接决定了你在VSCode终端里调用的究竟是哪个node——这一点才是关键。

• C:\Program Files\nodejs：Node.js官方安装的默认路径。卸载程序通常不会把它清干净。
• C:\Users\{用户名}\AppData\Roaming\npm：全局npm install -g的写入位置。这里面有很多脚本，比如vue-cli-service.cmd，它们硬编码了旧版node的路径，不清掉就是隐患。
• C:\Users\{用户名}\AppData\Roaming\npm-cache：npm的缓存目录。一旦损坏，可能会引发类似ERR_OSSL_PEM_ROUTINE的SSL错误。
• %LOCALAPPDATA%\Programs\Microsoft VS Code：旧版本VSCode的用户安装路径，很多人会把这里跟%APPDATA%\Code弄混，结果哪个都漏了。

注意：AppData是隐藏文件夹，不需要去折腾“显示隐藏项目”的开关，直接在资源管理器地址栏里粘贴完整路径，回车就能进去。

插件级的Node缓存：只清带 -cache 后缀的目录

VSCode的某些插件，比如ms-python.python、ms-vscode.vscode-typescript这类语言支持插件，会在~/.vscode/extensions/下解压并缓存语言服务器运行时的依赖。如果更新过程中断了，就会留下一个像ms-python.python-2024.12.0-cache这样的损坏包。VSCode启动时，会优先加载这个损坏的包，然后你就会看到“Failed to fetch extension”或“Cannot find module”的报错。

• 只清理名称里带-cache的子目录，比如ms-python.python-2024.12.0-cache。千万不要去动同名的主目录ms-python.python-2024.12.0，否则插件会彻底丢失，麻烦更大。
• 如果你习惯用PowerShell，有一行命令可以一键清理：Get-ChildItem "$env:USERPROFILE\.vscode\extensions" | Where-Object {$_.Name -match '-cache$'} | Remove-Item -Recurse -Force
• 清理完之后，重启VSCode，它会自动下载并解压最新的插件版本。这个方法比“禁用再启用”干净多了。

ts-node调试断点不命中？问题不在缓存

很多开发者遇到ts-node断点不命中的问题，第一反应就是去清缓存。但ts-node根本不写磁盘缓存——它是每次运行都在内存里实时转译.ts文件，不会生成.js或.js.map文件。所以，90%的断点不命中问题，根源在TypeScript版本不一致或者launch.json配置错误上。

• 在VSCode右下角点一下TypeScript版本号，选择“Use Workspace Version”。
• 检查launch.json里的runtimeArgs，必须是["--nolazy", "-r", "ts-node/register"]。很多人漏掉-r，或者直接把"ts-node"写成了runtimeExecutable，这都会失败。
• 如果项目启用了ESM（package.json里设置了"type": "module"），runtimeArgs就得换成["--loader=ts-node/esm"]。因为在ESM模式下，Node.js会忽略-r参数。

怎么验证配置是否生效？不妨试试做个简单测试：在launch.json的args里加一个不存在的路径，比如["${workspaceFolder}/src/nonexistent.ts"]。如果报Cannot find module，说明解析链是通的；如果静默失败，或者直接报语法错误，那配置就没起作用，需要重新排查。