vscode保存时自动格式化调用的是编辑器内置格式化服务接口，而非执行外部命令行脚本；它通过lsp向已注册插件（如prettier）发送格式化请求，由插件内联处理文档内容，不spawn shell、不调用prettier --write，配置加载取决于插件实现。
VSCode 保存时自动格式化不是“运行脚本”，它调用的是编辑器内置的格式化服务接口，不执行用户写的 prettier 或 black 命令行脚本——除非你手动配置了任务（Task）或钩子（如 husky + lint-staged），否则不存在“运行格式化脚本”这回事。
为什么 Ctrl+S 不等于执行 npm run format
VSCode 的 editor.formatOnSave 是编辑器原生机制：它向已注册的语言服务器（比如 Prettier 插件提供的 LSP）发送一个格式化请求，传入当前文档内容和光标位置等上下文，由插件内部决定如何重排代码。整个过程不 spawn shell、不调用 prettier --write、也不读取项目根目录下的 .prettierrc（除非插件自己实现该逻辑）。
- 插件是否读配置文件，取决于其实现——
esbenp.prettier-vscode会读，但vscode-eslint默认只做 fix-on-save，且仅限 ESLint 规则范围内的修复 - 如果你在终端里跑
npx prettier --write src/*.ts，那是独立进程；而 VSCode 保存触发的是插件内联处理，二者路径、环境变量、配置加载方式都不同 - 常见误解：以为开启
formatOnSave就等于加了 git commit hook——其实完全无关，它只作用于当前编辑器会话中的单个文件
如何让保存真正“运行外部脚本”
真要让 Ctrl+S 触发命令行脚本（比如强制走 prettier CLI 而非插件逻辑），必须绕过原生格式化机制，改用 tasks.json + 文件保存事件监听，但这属于高级定制，且有副作用：
- VSCode 没有原生“保存后执行 task”的触发器，只能靠第三方扩展（如
gruntfuggly.vscode-auto-run-command）监听files:didSave事件 - 需在
.vscode/tasks.json中定义 task，例如："command": "npx", "args": ["prettier", "--write", "${file}"] - 该方式会阻塞保存流程——如果脚本卡住或报错，文件可能无法写入磁盘
- 无法享受语言服务器的实时反馈（如格式化失败时的错误提示），出错只会显示“task failed”
editor.formatOnSaveMode: file vs modifications 容易踩的坑
这个配置项控制格式化范围，默认是 file，但有人为“提速”设成 modifications，结果发现格式化失效或行为诡异：
-
modifications模式依赖编辑器 diff 算法识别“改动行”，一旦文件含未提交的 Git 冲突标记（）、或存在大段注释/空行扰动，diff 可能漏掉真实变更区域 - Prettier 等工具本身不支持增量格式化，VSCode 在
modifications模式下检测到不支持，会静默 fallback 到全文件格式化，反而更慢 - 某些语言（如 TypeScript）在
modifications下可能跳过 import 排序、类型补全等跨行操作，导致格式不一致
格式化没反应？先看 Developer Tools 里的报错
打开命令面板（Ctrl+Shift+P），运行 Developer: Toggle Developer Tools，切换到 Console 标签页，保存文件时观察输出：
-
Failed to format document: Error: No formatter registered for 'typescript'→ 缺少对应语言的 formatter 插件，或editor.defaultFormatter没按语言块设置（比如写了全局"editor.defaultFormatter": "esbenp.prettier-vscode"，但没加"[typescript]": {...}） -
Formatting failed with exit code 1→ 插件调用了 CLI 工具但失败了，检查是否装了prettier包（全局 or 项目本地），路径是否被node_modules/.bin正确解析 - 空白无输出？可能是
editor.formatOnSave被工作区设置覆盖了——运行Preferences: Open Workspace Settings (JSON)确认当前生效配置
真正关键的不是快捷键多快，而是格式化动作是否稳定、可预期、与团队规则对齐。多数人卡在“以为开了开关就万事大吉”，却忽略了插件注册、语言块配置、配置文件加载优先级这些底层链路。
