vscode本身不支持“自动保存并运行”，需通过files.autosave触发保存后，再借助nodemon、watchexec等外部工具监听文件变化执行命令，或依赖vite等热更新服务；files.autosave仅控制落盘时机，不执行任何命令。
VSCode 本身没有“自动保存并运行”这个功能，保存和运行是两个独立动作，必须手动串联。所谓“保存即运行”，本质是 files.autoSave 触发磁盘写入后，靠外部机制（如任务、监听进程或服务热更新）感知文件变化并执行命令。
files.autoSave 配什么值才真正触发后续运行
选错模式会导致“改了没存”或“存了但根本没运行”。files.autoSave 只控制何时写入磁盘，不负责执行任何命令。
-
afterDelay：最稳妥，配合files.autoSaveDelay（建议800～1200），停顿后落盘，防抖且不易漏；设太小（如100）在 WSL 或远程开发中易卡顿 -
onFocusChange：切到终端、侧边栏、甚至点击 Git 面板都会触发保存——看似方便，但未验证的改动可能提前落盘，导致运行出错 -
onWindowChange：Alt+Tab 切走就保存，但 macOS 的 Spotlight、微信浮窗等也会让 VS Code 短暂失焦，容易误存 -
off：不是不能用，编辑.env、docker-compose.yml等敏感文件时，手动控制更安全
保存后怎么让 Python/Node.js 脚本自动运行
VSCode 没有原生“保存即执行”，必须靠外部监听或服务自身能力。npm 脚本类工具（如 Vite、Webpack Dev Server）自己监听文件，你只需确保 files.autoSave 生效即可；而普通脚本需额外搭链路。
- 用
nodemon：适合 Node.js，nodemon -x python main.py或nodemon --exec python main.py - 用
watchexec：跨语言更干净，watchexec -r --exts py --on-change "python main.py" - 避免用“Runner”类插件：它们常绕过 VS Code 的保存生命周期，导致格式化、Git 脏检查等逻辑失效
- 不要把监听命令写进
tasks.json并设为isBackground: true后指望它“一直运行”——任务系统不保活，窗口重启后监听就断了
editor.formatOnSave 和 files.autoSave 一起开，为什么代码总“跳”
这不是 bug，是执行顺序问题：files.autoSave 触发后，VS Code 先把原始内容写入磁盘，再调 editor.formatOnSave 格式化。如果格式化耗时长（比如大文件 + Prettier + ESLint 混用），你会看到光标回跳、缩进重排、甚至粘贴中的代码被意外修正。
- 临时解法：关掉
editor.formatOnSave，用快捷键Shift+Alt+F手动格式化 - 长期方案：加配置
"editor.formatOnSaveMode": "modifications"，只格式化改动行，减少干扰 - 注意：如果用了
prettier或black，它们的 CLI 模式比编辑器插件更稳定，可考虑用watchexec监听 + 格式化命令组合替代
多工作区、远程开发时，自动保存配置容易失效
图形界面里改的设置，可能只写入用户级 settings.json，而多根工作区或 SSH/WSL 场景下，工作区级设置优先级更高——结果就是你明明开了 afterDelay，却没反应。
- 务必手动编辑工作区根目录下的
.vscode/settings.json，写入"files.autoSave"和"files.autoSaveDelay" - 用
files.autoSaveExclude排除干扰路径，例如"**/dist/**"、"**/__pycache__/**"，避免保存触发无谓构建 - Python 项目中，
**/*.pyc和**/.mypy_cache/**也建议排除，否则保存时可能被误写或引发权限错误
真正的难点不在“怎么配”，而在理解 VS Code 的保存生命周期：它不关心你是否想运行，只负责把内容落盘；所有“自动化运行”都是你搭的桥，桥稳不稳，取决于监听工具是否可靠、触发时机是否合理、以及有没有被格式化或 Git 插件中途截胡。
