VSCode默认不自动保存，必须显式配置files.autoSave为off/afterDelay/onFocusChange之一（onWindowChange已移除）；选afterDelay需配files.autoSaveDelay，onFocusChange在编辑器失焦时立即保存，但易受格式化插件失败、工作区设置覆盖或文件锁定干扰。
VSCode 默认不自动保存，必须显式配置 files.autoSave 才能生效；手动保存快捷键 Ctrl+S（Windows/Linux）或 Cmd+S（macOS）始终可用，与自动保存是否开启无关。
files.autoSave 的四个可选值及适用场景
这个设置不是布尔开关，而是字符串枚举，选错值等于没开：
-
off：彻底关闭，依赖手动保存或插件——这是默认值，别以为“没动过就是开着” -
afterDelay：停笔后延迟写入，需同步配files.autoSaveDelay（单位毫秒），设太小（如 100）会导致频繁刷盘、卡顿；设太大（如 5000）易漏存 -
onFocusChange：当前编辑器 Tab 失去焦点时立即保存，覆盖 Alt+Tab 切出、点终端、切到侧边栏等动作；但最小化窗口、打开命令面板（Ctrl+P）不算失焦，不会触发 -
onWindowChange：已在 VSCode 1.80+ 版本中移除，配置文件里写它会被静默忽略，不报错也不生效
为什么设置了 onFocusChange 却“看起来没保存”
常见干扰项不是设置本身，而是保存流程被中途拦截：
- 格式化插件（如 Prettier）启用了
editor.formatOnSave，但代码有语法错误导致格式化失败 → VSCode 中止整个保存流程，文件仍为 dirty 状态 - 工作区
.vscode/settings.json里写了"files.autoSave": "off"，它会覆盖用户级设置 - 某些语言专属配置（如
[javascript]块）没声明files.autoSave，该语言文件不受影响 - 文件被外部进程锁定（如正在被 Webpack watch 监听并热重载），VSCode 可能因权限/占用问题写入失败，但 UI 不提示
手动触发保存的边界与可靠性
Ctrl+S / Cmd+S 是唯一 100% 可控的保存方式，但它也有隐含行为：
- 只保存当前激活的编辑器 Tab，不批量保存所有 dirty 文件
- 若启用了
editor.formatOnSave，它会先格式化再写入磁盘，耗时略长；禁用后响应更快 - 在 Git 提交前执行
Ctrl+S并不能替代git add，它只确保文件内容落盘，不影响暂存区状态 - 远程开发（SSH/WSL）场景下，
Ctrl+S仍走本地 VSCode 进程，但实际 I/O 发生在远端，网络延迟可能导致“按键后稍等片刻才真正写入”
最常被忽略的是：自动保存只对已修改未保存（dirty）的文件起作用，干净文件不会被重复写入；而手动快捷键无论文件是否 dirty 都会强制触发一次写操作——这点在调试文件监听逻辑时特别关键。
