应选 onFocusChange 或 onWindowChange 模式，避免默认 afterDelay；前者在编辑器失焦时立即保存，最可靠；后者在窗口失焦时保存，适合多任务；二者均忽略 files.autoSaveDelay。
VSCode 的自动保存不是“开个开关”就完事的，关键看保存时机和触发条件——默认的 afterDelay 模式容易丢修改，而 onFocusChange 或 onWindowChange 才真正省心。
自动保存模式怎么选：别用默认的 afterDelay
VSCode 默认是 files.autoSave: "afterDelay"，靠计时器触发（默认 1000ms），但这个延迟在快速切换文件、切出窗口、甚至 Alt+Tab 的瞬间极易失效——你改了三行，没来得及触发保存就切走了，结果 Git 差异里全是空的。
-
onFocusChange：当前编辑器失去焦点时立刻保存（比如点击侧边栏、跳到终端、点另一个 tab）——最符合直觉，也最不容易丢内容 -
onWindowChange：VSCode 窗口失焦时保存（比如切到浏览器或微信）——适合多任务场景，但对单窗口多 tab 用户略保守 - 绝对避免
afterDelay配合短延迟（如 300ms），CPU 负载高且仍不可靠；也不建议off+ 手动Ctrl+S，违背“自动”初衷
files.autoSaveDelay 只在 afterDelay 下生效
这个配置项常被误认为“全局保存延迟”，其实它只对 afterDelay 模式起作用。一旦你选了 onFocusChange 或 onWindowChange，files.autoSaveDelay 就完全被忽略——不用删，留着也无害，但别指望它能调快保存速度。
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
- 检查当前模式：打开设置（
Ctrl+,），搜auto save，看Files: Auto Save下拉值 - 想确认是否生效？改一行 → 点击 Explorer 树中的另一个文件 → 回去看原文件右上角是否还有“未保存”圆点
配合 files.hotExit 和 files.restoreWindows 防崩溃丢代码
自动保存解决的是“主动编辑中”的数据落盘，但 VSCode 崩溃或断电时能否恢复，取决于这两个配置：
-
files.hotExit:"onExitAndWindowClose"（推荐）——关窗口或退出 VSCode 时保留未保存文件状态，重启后自动还原为“已修改未保存” -
files.restoreWindows:"all"——重启后不仅恢复窗口，还恢复所有打开的编辑器（含未保存临时文件） - 注意：这两项不替代自动保存，而是兜底。如果同时设为
off，哪怕开了onFocusChange，崩溃后照样丢内容
某些语言/扩展会干扰自动保存行为
比如 Prettier、ESLint 自动修复、Tailwind CSS IntelliSense 的“class name 补全”等，在保存瞬间触发格式化或注入逻辑，可能造成光标跳转、内容重排，甚至因格式化失败导致保存中断（表现为文件右上角持续显示星号，但实际没写入磁盘）。
- 排查方法：禁用所有扩展 → 测试自动保存是否稳定 → 逐个启用，观察异常出现时机
- 常见冲突点：
editor.formatOnSave开启时，若格式化工具未就绪（如 ESLint 还在初始化），保存可能卡住；可改用editor.formatOnSaveMode:"modifications"减少干扰 - 敏感项目（如生成式代码、JSON Schema 编辑）建议关掉
editor.formatOnSave，靠手动Shift+Alt+F控制时机
自动保存真正的难点不在开关本身，而在它和格式化、热重载、Git 状态、崩溃恢复之间的耦合——调对模式只是第一步，后续得盯着编辑器右上角那个小圆点是否真消失了，而不是假装它存在。
