要真正关闭VS Code自动保存，必须同时禁用files.autoSave、editor.formatOnSave、editor.codeActionsOnSave、files.trimTrailingWhitespace、files.insertFinalNewline，并检查工作区及语言专属设置和插件干扰。
files.autoSave 设为 off 不代表真关掉了
很多人改了 files.autoSave 为 "off" 就以为万事大吉，结果发现文件还是被悄悄保存了。这不是设置没生效，而是其他机制在“代劳”——VS Code 的自动保存逻辑是分层的，files.autoSave 只管“编辑状态触发的保存”，不管“格式化、修复、粘贴等动作顺带引发的落盘”。
-
editor.formatOnSave开着时，哪怕files.autoSave是"off"，你手动按 Ctrl+S，也会先格式化再保存，看起来像“自动保存又活了” -
editor.codeActionsOnSave里若含"source.fixAll"或"source.fixAll.eslint"，同样会在保存瞬间触发修复并落盘 -
files.trimTrailingWhitespace和files.insertFinalNewline这类“保存时清理”选项，只要启用，每次手动保存都会写入磁盘，且不依赖files.autoSave
必须同步关闭的隐藏保存开关
要让文件真正“只在你按 Ctrl+S 时才保存”，得把所有可能偷偷落盘的配置一并关掉。这些不是可选建议，而是硬性条件。
- 在
settings.json中显式设"files.autoSave": "off"（不能是true、false、数字或空字符串，否则整个配置失效） - 关掉格式化联动：
"editor.formatOnSave": false - 关掉代码修复联动：
"editor.codeActionsOnSave": { "source.fixAll": "never", "source.fixAll.eslint": "never" } - 关掉保存时清理：
"files.trimTrailingWhitespace": false、"files.insertFinalNewline": false - 检查是否有语言专属覆盖，比如
"[javascript]": { "editor.formatOnSave": true }—— 这类块会优先于全局设置，必须一并删掉或设为false
工作区设置和插件才是最大干扰源
90% 的“关不掉”问题，根源不在用户设置，而在项目级或插件级覆盖。VS Code 的配置优先级是：语言专属 > 工作区（.vscode/settings.json） > 用户设置。你改了全局，但项目里自带一个 "files.autoSave": "onFocusChange"，那就白搭。
- 打开当前项目根目录，检查是否存在
.vscode/settings.json；如果存在，直接搜"autoSave"、"formatOnSave"、"codeActionsOnSave"，全删或设为false/"never" - 禁用可疑插件临时验证：比如 Prettier、ESLint、Beautify、Auto Rename Tag —— 它们常自带保存钩子，哪怕你关了
editor.formatOnSave，某些版本仍会绕过设置强制格式化 - 注意未命名文件（
Untitled-1）和只读文件：它们根本不受files.autoSave控制，但手动保存时会弹另存为，容易误判为“自动保存还在运行”
验证是否真关干净了
改完别急着关设置页，用最笨但最准的办法验证：开一个新文件（Ctrl+N），输入点内容，不按 Ctrl+S，直接关掉标签页。如果弹出“是否保存”的对话框，说明关成功了；如果直接关闭没提示，那肯定还有某处配置在自动落盘。
- 不要依赖“有没有 * 星号”来判断：星号只表示“有未保存修改”，不反映是否被自动保存过
- 观察文件系统时间戳：改完内容后等几秒，用命令行执行
ls -l filename（macOS/Linux）或dir filename（Windows），看修改时间是否变动；若没按 Ctrl+S 却变了，说明仍有后台保存行为 - 特别留意调试场景：启动调试（F5）不会触发
files.autoSave，但某些插件（如 Debugger for Chrome）可能在 launch 前自动保存当前文件，这属于插件行为，需单独排查
真正的“彻底关闭”不是只动一个开关，而是切断所有可能的落盘路径。最容易被忽略的是工作区配置和语言专属设置，它们藏得深、优先级高，不逐个翻出来确认，永远关不干净。
