vscode自动保存与修复需分别配置：files.autoSave控制写盘时机（推荐onFocusChange或afterDelay 1500–2500ms），editor.codeActionsOnSave触发修复动作（如source.fixAll.eslint），二者协同防丢内容；hotExit+restorewindows保障崩溃恢复。
vscode 的自动保存和自动修复不是“开个开关就完事”，而是两套独立机制需要分别配置、协同工作——files.autosave 控制是否写入磁盘，editor.codeactionsonsave 控制保存时是否执行修复动作；二者都未启用时，你每次 ctrl+s 才算真正落地，极易丢内容。
怎么选对 files.autoSave 模式？别迷信“最安全”
很多人一上来就设 onWindowChange 或 afterDelay 100ms，结果频繁写盘卡顿、误存半成品、git 提交一堆临时注释。关键看你的工作流节奏：
-
onFocusChange：适合边写代码边切终端查日志、或频繁在多个文件间跳转的人——离开当前编辑器那一刻才保存，既防丢又不扰节奏 -
afterDelay（推荐 1500–2500ms）：适合专注单文件开发，比如写函数、改配置、写 Markdown。延迟太短（如 300ms）容易把没想好的变量名、半截 if 写进磁盘；太长（>5000ms）崩溃时仍可能丢 5 秒内容 -
off不是不行，但仅建议用于敏感场景（如编辑生产环境密钥文件），且必须配合files.hotExit+window.restoreWindows双保险
注意：onWindowChange 是 VSCode 1.85+ 新增模式，行为比 onFocusChange 更激进（切微信也算），但某些多显示器用户会遇到焦点判断不准的问题，实测稳定性不如前两者。
editor.codeActionsOnSave 怎么配才不翻车？
这个设置本身不格式化、不 lint、不跑测试，它只是“保存时触发哪些动作”的开关。真正干活的是你装的语言扩展（ESLint、Prettier、typescript 等）。常见踩坑点：
- 只写
"source.fixAll": true但没装 ESLint 扩展 → 什么都不会发生，控制台也无报错 - 同时开了
editor.formatOnSave和source.formatDocument→ Prettier 可能被调两次，导致缩进错乱、光标乱跳 - 在 TypeScript 项目里启用了
source.fixAll，但没关掉typescript.preferences.includePackagejsonAutoImports→ 保存时疯狂自动加 import，干扰手写逻辑
推荐最小可用组合（放入 .vscode/settings.json）：
"editor.codeActionsOnSave": { "source.organizeImports": true, "source.fixAll.eslint": true }, "editor.formatOnSave": false, "editor.defaultFormatter": "esbenp.prettier-vscode"这样 ESLint 修错误、Prettier 统一格式、Import 自动整理，三者各司其职，不打架。
崩溃/断电后还能找回未保存内容吗？关键看这三个配置
自动保存再稳，也防不住系统级崩溃。VSCode 的“热退出”（hot exit）才是最后防线，但它默认开启却常被覆盖：
-
files.hotExit必须是"onExitAndWindowClose"（不是"onExit"），否则关一个窗口就丢那个窗口的内容 -
window.restoreWindows推荐设为"all"，而不是"preserve"——后者只恢复上次关闭前的窗口布局，但不会还原未保存的修改状态 -
files.autoSave设为off时，files.hotExit就是你唯一的救命稻草；但如果连它也被设成off或onExit，那崩溃即失联
验证方法：打开一个文件，输入几行字不保存 → 任务管理器强制结束 VSCode 进程 → 重新启动 → 底部应弹出 Reopen Closed Editors 提示。没弹？回头检查上面三项。
最容易被忽略的一点：VSCode 的恢复能力依赖本地临时目录（如 macos 的 ~/Library/application Support/Code/Backups），如果该路径被清理工具误删、或磁盘满、或权限异常，hotExit 就形同虚设——定期检查 code --status 输出里的 Backup Path 是否可读写，比背配置更重要。