autoSaveDelay仅在files.autoSave设为"afterDelay"时生效，需配整数毫秒值（如1200），设错模式或格式将被静默忽略；推荐本地800～1200ms、远程1500～2500ms，并关闭自动格式化防卡顿。
autoSaveDelay 必须配合 autoSave 设为 afterDelay 才生效，设错模式或填错单位（比如写小数、带单位字符串）会导致它完全被忽略。
为什么改了 autoSaveDelay 却没反应
常见错误是只改了延迟值，但 autoSave 还停在 off 或 onFocusChange。VSCode 会静默丢弃这个配置——它不是报错，而是压根不读。
- 打开设置（
Ctrl+,），搜files.autoSave，确认下拉选中的是afterDelay - 再搜
files.autoSaveDelay，填纯整数，比如1200，别写"1200ms"或1200.0 - 检查
settings.json里有没有拼错键名：旧版用files.autoSave，新版统一用autoSave；混用会导致覆盖失效 - 重启 VSCode 不必要，但改完后可按
Ctrl+Shift+P→ 输入Developer: Reload Window强制刷新配置
autoSaveDelay 设多少才不卡又不丢内容
它不是“越小越好”，也不是“越大越安全”。真实瓶颈常在磁盘 I/O 或格式化插件，而非延迟本身。
- 本地开发：推荐
800～1200。低于500容易和 TypeScript 语言服务冲突，出现“保存了但修复没应用” - WSL / SSH 远程开发：必须调高到
1500～2500，否则频繁触发Failed to save 'xxx': Unable to write file - 大文件（>1MB）或网络挂载盘：避开
300～500区间，否则打字卡顿、光标跳动 - 别设
0或空值——VSCode 会退化为onFocusChange行为，失去可控性
保存卡顿？先关掉 editor.formatOnSave
很多人以为调低 autoSaveDelay 能缓解卡顿，结果发现保存还是慢 1–2 秒。真相往往是 Prettier 或 ESLint 在后台跑格式化，而 autoSaveDelay 只控制“什么时候写磁盘”，不控制“写什么”。
- 把
editor.formatOnSave设为false，观察是否还卡 - 改用
editor.codeActionsOnSave+"source.fixAll"，只修错不重排版 - 或者干脆禁用自动格式化，用
Shift+Alt+F手动触发——需要时才做，不干扰编辑流 - 远程开发时，务必同步关掉
files.autoSaveOnWindowChange，避免切窗口时强行撞上未完成的格式化
真正容易被忽略的点是：延迟值只对“最后一次编辑操作之后”的静默期起作用。持续打字会不断重置倒计时，所以它本质是个防抖参数，不是定时器。设得太低，机器压力上去了，人眼却根本感知不到“更快”；设太高，防抖就变成了“等你忘了自己改过啥”。
