vscode的files.autosave没反应，90%是因被工作区设置覆盖、语言专属配置禁用、插件静默拦截（如eslint格式化失败），或未满足触发条件（如文件无路径、未修改）；它仅接受"off"/"afterdelay"/"onfocuschange"/"onwindowchange"四字符串值，设true/1等非法值即失效，且afterdelay模式必须同步配置files.autosavedelay（推荐800～1500毫秒）。
VSCode 的 files.autoSave 没反应，90% 不是配置错了，而是被更高优先级设置覆盖、触发条件不满足，或保存流程被插件静默中断。
为什么改了 files.autoSave 却没保存
它不是布尔开关，只接受四个字符串值："off"、"afterDelay"、"onFocusChange"、"onWindowChange"。设成 true、1、"true" 或空值，VS Code 直接忽略，等同于 "off"。
- 右下角状态栏显示「工作区」时，说明正在读取项目根目录下的
.vscode/settings.json—— 里面哪怕只有一行"files.autoSave": "off"，就彻底覆盖你的全局设置 - 语言专属配置也生效：比如
"[markdown]": { "files.autoSave": "off" }，所有.md文件都会跳过自动保存 - 新建的
Untitled-1文件没有磁盘路径，files.autoSave完全不作用于它；必须先Save As落盘，右上角出现 ● 才开始监听 - 只读文件、Git 合并冲突中的临时标记行（如
）也不触发自动保存
afterDelay 模式必须配 files.autoSaveDelay
选 "afterDelay" 却没反应？大概率是漏了配套参数。这个模式依赖 files.autoSaveDelay（单位毫秒），不设它，延迟默认为 0，等于每敲一个字符都尝试保存——在 WSL、远程容器或机械硬盘上容易卡顿甚至失败，VS Code 可能直接放弃。
- 推荐值：800～1500；设 300 容易和格式化插件冲突，设 3000 又可能切走就忘了改了啥
- 延迟只对“停止输入”起作用：连续打字不会触发，停顿超过设定时间才落盘
- 注意：这个延迟不保证“实时”，编辑完立刻切终端查日志，可能还没来得及保存
插件静默拦截保存，状态栏却显示“已保存”
启用 editor.formatOnSave 后，Prettier、ESLint 或 Python Linter 格式化失败时，VS Code 会中止整个保存流程——磁盘内容仍是旧的，但状态栏一闪而过“已保存”，极易误判。
- 打开命令面板（
Ctrl+Shift+P），运行Developer: Toggle Developer Tools，看 Console 是否有Failed to save或codeActionsOnSave报错 - 临时禁用所有扩展再测试；确认问题后，单独调整对应插件的
editor.codeActionsOnSave配置 - 某些远程场景（WSL / SSH）下，格式化插件启动慢，也可能导致保存超时被丢弃
设置项刷新与恢复方法
VS Code 设置按优先级生效：工作区 > 用户 > 默认。想确认当前真正生效的值，不能只看图形界面设置页。
- 打开命令面板（
Ctrl+Shift+P），运行Preferences: Open Workspace Settings (JSON)，直接检查.vscode/settings.json内容 - 同样可运行
Preferences: Open User Settings (JSON)查看用户级设置 - 右下角语言模式（如 “Python”）点一下 →
Configure Language Specific Settings，检查该语言是否被单独关掉 - 想快速重置：删掉
.vscode/settings.json中的files.autoSave行，或整个文件；重启 VS Code 后，用户设置就会重新接管
真正容易被忽略的是：自动保存只响应“已修改且有路径”的文件，不关心你写了多少行，只认右上角那个 ●；而插件拦截保存时，VS Code 不报错、不提示、不回滚，只悄悄维持旧内容——这种静默失败比功能缺失更危险。
