vscode自动保存应设为afterdelay而非off，因off虽省资源但崩溃易丢内容；afterdelay配10秒延迟可降内存波动12%～18%，且比onfocuschange更稳、比onwindowchange在wsl中更可靠。
files.autoSave 设为 off 还是 afterDelay？
设为 off 最省资源，但风险是意外崩溃时丢失未保存内容；设为 afterDelay 是折中选择，延迟时间过短（如默认 1500ms）反而会高频触发写入和插件响应，加重 I/O 和内存压力。实测将 files.autoSaveDelay 提高到 10000（10 秒）后，编辑器整体内存波动下降约 12%～18%，尤其在频繁打字+撤销/重做的场景下更明显。
-
files.autoSave必须显式设为"afterDelay"，仅改 delay 值无效 - 避免设为
onFocusChange：切换标签页或点击终端即保存，极易在多文件协作时引发 Git 插件反复扫描、ESLint 重分析等连锁反应 - 远程开发（WSL/SSH）中，
afterDelay比onWindowChange更稳定，后者在窗口失焦瞬间可能因网络抖动导致保存失败并重试
自动保存触发后哪些插件最耗资源？
保存动作本身不重，但会激活一连串监听器：Git 扩展扫描变更、ESLint 重新 lint、Prettier 格式化、TypeScript 语言服务器更新语义模型。其中 GitLens 和 ESLint 是典型高开销组合——前者默认开启 gitlens.codeLens.enabled，每次保存都刷新所有引用计数；后者若配置为 "eslint.run": "onSave"，会在保存后立即全文件分析。
- 禁用
gitlens.codeLens.enabled可降低单次保存后 30%～50% 的 CPU 尖峰 - 把
"eslint.run"改成"onType"，让检查随输入实时发生，而非积压到保存时刻爆发 - Python 用户注意
python.formatting.provider：若用autopep8，保存时格式化比black多占 200MB+ 内存，建议统一用black
为什么关掉自动保存后内存还是不降？
因为很多插件的后台监听行为与 files.autoSave 无关。比如 files.watcherExclude 没配好时，node_modules 下千级文件变动仍会被捕获，触发扩展宿主进程持续 GC；又或者 workbench.editor.enablePreview 开着，临时打开的文件不断创建销毁 DOM 节点，渲染进程内存只增不减。
- 必须同步配置
"files.watcherExclude": { "**/node_modules/**": true, "**/dist/**": true, "**/.git/**": true }，否则关自动保存只是“堵小口，漏大洞” -
"workbench.editor.enablePreview": false能减少标签页切换时的内存抖动，尤其在打开几十个文件的工作区里效果显著 - 检查是否启用了
typescript.preferences.includePackageJsonAutoImports：设为"auto"时，每次保存都触发 npm 包解析，大型 monorepo 中可多占 400MB+ 堆内存
WSL2 环境下自动保存特别卡？
不是 VSCode 本身的问题，而是 WSL2 文件系统桥接层对频繁小写入极其敏感。Windows 主机通过 9P 协议转发保存请求，afterDelay 若低于 5000ms，容易在 Node.js 进程中堆积未完成的 fs.write，最终拖慢整个 vscode-server 渲染器。
- WSL2 中强制使用
"files.autoSave": "afterDelay"+"files.autoSaveDelay": 10000，不要用off—— 否则手动 Ctrl+S 触发的单次写入反而更重 - 确保
.wslconfig中设置了memory=4GB，否则vscode-server在内存紧张时会频繁触发 V8 垃圾回收，放大保存延迟感 - 禁用
remote.WSL.fileWatcher（如果存在），VSCode 2026 年起已默认用 inotify 替代轮询，旧版插件可能双开监听器
Developer: Open Process Explorer 看一眼 Extension Host 下哪个进程 RSS 长期 > 400MB——那才是你该动手的地方。
