VSCode保存卡在“Saving…”是因formatOnSave同步等待格式化器响应超时或失败，常见于Prettier/ESLint路径错误、未安装、多插件冲突或CLI不可用；应验证npx prettier能否正常运行、指定唯一defaultFormatter、改用modificationsIfAvailable模式并调高formatOnSaveTimeout。
为什么 editor.formatOnSave 一开就卡住保存
VSCode 的 editor.formatOnSave 是同步阻塞式调用，它会等格式化工具（如 prettier、eslint）返回结果才真正落盘。一旦 CLI 找不到、路径错误、版本不兼容，或多个插件争抢默认格式化权，就会卡在“正在保存……获取格式化结果”。常见现象是右下角转圈、光标不动、文件状态栏长时间显示 Saving…。
- 终端进项目根目录运行
npx prettier --write src/index.ts --loglevel warn，报Cannot find module 'prettier'→ VSCode 必然卡住 - 同时启用 Prettier 和 ESLint 插件但没设
editor.defaultFormatter→ VSCode 先试 Prettier，失败再试 ESLint，双倍等待 -
editor.formatOnSaveTimeout保持默认 750ms，但实际格式化要 900ms → 直接超时卡死
files.autoSaveDelay 设了却没反应？检查这三处
files.autoSaveDelay 只在 files.autoSave 设为 "afterDelay" 时生效；填错模式、单位或键名，VSCode 会静默忽略，而不是报错。
- 打开设置（
Ctrl+,），搜files.autoSave，确认下拉选中的是afterDelay（不是onFocusChange或off） - 搜
files.autoSaveDelay，填纯整数，比如1200，别写"1200ms"或1200.0 - 检查
settings.json里键名是否统一：新版用autoSave和autoSaveDelay，旧版可能混用files.autoSave，冲突会导致覆盖失效
怎么让保存不卡又不丢内容
延迟值本质是防抖参数，不是定时器——持续打字会不断重置倒计时。设得太低（如 300）容易和 TypeScript 语言服务冲突；设太高（如 10000）等于主动留 10 秒空白期，断电即丢失。
- 本地开发推荐
800–1200；WSL / SSH 远程开发必须调高到1500–2500 - 大文件（>1MB）或网络挂载盘，避开
300–500区间，否则打字卡顿、光标跳动 - 绝对别设
0或空值——VSCode 会退化为onFocusChange行为，失去可控性 - 务必确认工作区
.vscode/settings.json没写"files.autoSave": "off"——它优先级高于用户设置
绕过卡顿但保留格式化能力的实操配置
不用关掉 editor.formatOnSave，也能避免阻塞：关键在控制“何时调用”和“调用失败怎么办”。
- 把
editor.formatOnSaveMode改成"modificationsIfAvailable"：格式化器可用时只处理你改过的行；不可用时直接跳过，不阻塞保存 - 把
editor.formatOnSaveTimeout提高到1200，给 CLI 更合理响应窗口 - 清空
editor.codeActionsOnSave（设为{}），或至少关掉耗时项：{"source.fixAll": false, "source.organizeImports": false} - 如果只写 JS，直接关掉
typescript.suggest.autoImports，比等它报错再禁用更省资源
真正容易被忽略的是：autoSaveDelay 控制的是“最后一次编辑后静默多久才保存”，它不干预格式化本身。保存卡顿的根因几乎总在格式化链上，而非延迟数值——先验证 npx prettier 能否跑通，再调参数，顺序错了白忙活。
