必须设为onfocuschange或onwindowchange才能真正防丢；untitled-1文件未保存路径前自动保存完全不生效。afterdelay模式因1秒延迟及内核缓存问题易丢代码，且小写入拖慢低端ssd或wsl2，推荐延迟设为1500ms。
files.autoSave 必须设为 onFocusChange 或 onWindowChange，否则无法真正防丢；新建的 Untitled-1 文件不保存路径前，自动保存完全不生效。
为什么 afterDelay 模式容易丢代码
设成 "files.autoSave": "afterDelay" 且延迟为 1000ms（默认），等于在每次修改后留出整整 1 秒的“无保护窗口”——VSCode 崩溃、断电、强制杀进程，这 1 秒内的改动就没了。
更隐蔽的问题是：小文件（比如 JSON 配置、JSX 片段）在 SSD 上可能被内核缓存延迟刷盘，afterDelay 触发写入后立刻被监听工具（如 Webpack、nodemon）捕获，但实际磁盘内容还没落稳，导致热更新失败或读到脏数据。
- 别调低
files.autoSaveDelay到 200ms 以下：频繁小写入会拖慢低端 SSD 或远程文件系统（如 WSL2 的 /mnt/c） - 如果必须用
afterDelay，建议配"files.autoSaveDelay": 1500，平衡响应与稳定性 - 真实场景中，
onFocusChange的触发时机（切出编辑器标签页/终端/浏览器）更贴近你“刚改完想试一下”的动作节点，天然契合工作流
onFocusChange 生效但文件还是没保存？检查这三个地方
自动保存开关开了，焦点一换也看到右下角弹出“已保存”，但终端里 node server.js 没反应，或者 Git 看不到变更——问题大概率不在 VSCode。
-
Untitled-1文件没指定路径：标题栏带“未命名”字样的文件永远不会写入磁盘，Ctrl+S 一次再编辑是硬性前提 - 插件拦截保存流程：Prettier、ESLint Fix on Save 等会在保存前格式化，若格式化报错（如语法错误、配置缺失），整个保存会被静默中断；看右下角状态栏是否闪现红色错误提示
- 文件系统监听失效：Linux 下 inotify 限制太低（
/proc/sys/fs/inotify/max_user_watches默认 8192），Webpack 或 nodemon 就收不到变更事件；可临时用chokidar轮询替代，或提高限制值
工作区设置会覆盖全局，.vscode/settings.json 是第一排查点
你在用户设置里把 files.autoSave 设成了 onFocusChange，但打开某个项目后自动保存又失效了——八成是项目根目录下的 .vscode/settings.json 里写了冲突配置。
- 打开该文件，搜索
"files.autoSave"，如果值是"off"或"afterDelay"，直接删掉这行，让全局设置生效 - Remote-SSH 或 WSL 场景下，用户设置在远程机器上，不是本地；需在远程端的
~/.vscode/settings.json中配置 - 某些团队脚手架（如 create-react-app 初始化项目）会自带
.vscode/settings.json，默认关掉 autoSave，务必手动检查
files.hotExit 不是摆设，它是崩溃后恢复的最后一道防线
即使开了 onFocusChange，如果 VSCode 自身卡死或被 kill -9，写入动作根本没机会执行。这时 "files.hotExit": true（默认开启）才起作用——它把未保存内容存在内存+本地临时区，重启后自动弹出恢复提示。
- 确认没被禁用：在设置里搜
hotExit，确保值为true，而不是onExitAndWindowClose（后者只在正常退出时生效） - 这个机制依赖
~/.config/Code/Backups/（Linux/macOS）或%APPDATA%\Code\Backups\（Windows），别用清理软件误删 - 它不解决“保存后被覆盖”问题（比如多人协作时 git pull 强制覆盖），所以
git commit仍是不可替代的防丢手段
onFocusChange 就是把这个本能自动化；而所有配置里最容易被忽略的，是新建文件必须先存路径——这点没做，其他设置全是空转。
