VSCode自动保存默认关闭，需设files.autoSave为afterDelay/onFocusChange/onWindowChange之一；formatOnSave配合格式化工具实现“自动修复”，但依赖语言识别、扩展安装及默认格式化器设置。
VSCode 的自动保存默认是关闭的，必须手动开启；所谓“自动修复”不依赖自动保存本身，而是由格式化工具（如 Prettier、ESLint）配合保存时触发（即 formatOnSave）实现。
如何开启 autoSave 及其三种触发模式
VSCode 的自动保存由 files.autoSave 控制，它不是开/关二选一，而是有四种取值：off（默认）、afterDelay、onFocusChange、onWindowChange。实际常用的是前三个：
-
afterDelay：在编辑停止files.autoSaveDelay毫秒后保存（默认 1000，即 1 秒），适合多数人 —— 不打断输入节奏，又不至于太久不存 -
onFocusChange：当前文件失去焦点时保存（比如切到终端、另一个标签页），适合多文件频繁切换的场景 -
onWindowChange：VSCode 窗口失焦时保存（比如 Alt+Tab 切到浏览器），风险较高：若你习惯边写代码边查文档，可能意外触发保存，而此时代码未必可运行
设置方式：打开设置（Ctrl+,），搜索 auto save，点击下拉选择对应模式；或直接编辑 settings.json：
{
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 800
}
formatOnSave 是什么，为什么它常被误认为“自动修复”
editor.formatOnSave 才是真正决定“保存时是否调用格式化工具”的开关。它本身不修复错误，只在保存动作发生后，调用已启用的语言格式化器（如 JavaScript 的 esbenp.prettier-vscode 或 TypeScript 的内置格式化器）重排代码结构。
- 必须先安装对应语言的格式化扩展（例如 Vue 项目需装
Vue.js Extension Pack，否则保存时无反应） - 若同时启用了
files.autoSave和editor.formatOnSave，格式化会随自动保存悄悄执行 —— 这就是所谓“自动修复缩进/引号/分号”的真实链路 - 注意冲突：某些 ESLint 配置启用
eslint.codeAction.onSave.fixAll后，会覆盖 formatOnSave 行为，优先走 ESLint 修复逻辑
常见失效场景和排查点
开了 autoSave 和 formatOnSave 却没反应？大概率卡在这几个地方：
- 当前文件没有被识别为对应语言：检查右下角语言模式（如显示为
Plain Text），点击后手动选成JavaScript或TypeScript - 工作区禁用了用户级设置：项目根目录有
.vscode/settings.json，且其中写了"editor.formatOnSave": false，会覆盖全局设置 - 格式化工具未设为默认：多个格式化扩展共存时（如 Prettier + ESLint），VSCode 不知道该用谁，需右键文件 →
Format Document With...→ 选中并设为默认 - 保存被拦截：某些插件（如 GitLens）或自定义任务可能监听了保存事件并阻止默认行为，可临时禁用插件验证
要不要开 autoSave？关键看你的协作与调试习惯
自动保存不是银弹。它省去 Ctrl+S 动作，但也会让“保存”这个明确的操作意图消失 —— 比如你刚删了一段逻辑，还没测试就切走了，autoSave 已把不完整状态提交到 Git；或者调试时想保留一个“故意出错”的临时版本用于比对，autoSave 会默默覆盖掉。
更稳妥的做法是：日常开发用 afterDelay（延迟 800–1200ms），配 editor.formatOnSave；但在写新功能、改核心逻辑、或需要反复对比 diff 时，主动关掉 autoSave，回归手动保存节奏。真正的“修复能力”不在保存动作本身，而在你配置的格式化规则是否合理、是否与团队一致。
