files.autoSaveDelay 只在 files.autoSave 为 "afterDelay" 时生效，单位毫秒，需设为整数且配置位置正确；其他保存模式下该值被忽略，且低延迟易引发性能、冲突或保存失败问题。
autoSaveDelay 设置不生效？检查配置位置和类型
VSCode 的自动保存延迟不是靠 files.autoSave 开关控制的，而是由 files.autoSaveDelay 这个独立配置项决定，单位是毫秒。但它只在 files.autoSave 设为 "afterDelay" 时才起作用——设成 "onFocusChange" 或 "onWindowChange"，这个延迟值会被完全忽略。
- 必须在用户设置或工作区设置中显式写入
"files.autoSaveDelay": 1000（不能只改autoSave） - 值必须是整数，小数（如
500.5）会被静默转为500，但 VSCode 不报错 - 如果用 JSON 配置，注意逗号结尾、引号闭合，漏一个逗号会导致整个 settings.json 解析失败，
autoSaveDelay就不会加载
为什么改了 autoSaveDelay 还是立刻保存？
常见原因是触发模式没对上。VSCode 只有在 files.autoSave 是 "afterDelay" 时，才会启用计时器逻辑；其他模式下，保存行为由焦点/窗口状态驱动，和延迟毫秒无关。
-
"afterDelay"：编辑后等待指定毫秒，无新输入则保存；有新输入则重置计时器 -
"onFocusChange"：切走当前文件（比如点别的 tab 或外部窗口）就立即保存，不等延迟 -
"onWindowChange"：切出整个 VSCode 窗口时才保存，同样无视autoSaveDelay
如果你希望“打完一行按回车就等 300ms 再保存”，那必须选 "afterDelay" 并配 "files.autoSaveDelay": 300。
延迟太短导致频繁保存，影响性能或 Git 脏检查
autoSaveDelay 设得太小（比如 100），容易在快速输入、补全、粘贴时反复触发保存，尤其在大文件或开启 ESLint 自动修复时，可能卡 UI 或生成大量中间 Git diff。
- 建议最小值设为
300，低于这个值人眼几乎感知不到差异，但机器压力明显上升 - 对 TypeScript/JS 项目，如果开了
editor.codeActionsOnSave，延迟低于500容易和语言服务响应冲突，出现“保存了但修复没应用”现象 - 某些远程开发场景（SSH、WSL），磁盘 I/O 较慢，
autoSaveDelay小于800可能导致保存失败，错误信息是：Unable to write file 'xxx' (Unknown (FileSystemError): Error: EBUSY: resource busy or locked)
不同平台或版本的兼容性注意点
VSCode 1.75+ 才正式将 files.autoSaveDelay 列为稳定配置项；旧版本（如 1.6x）虽然识别该字段，但实际行为不稳定，有时会退化为固定 1000ms。
- Windows 上某些杀毒软件会锁住刚写入的文件，导致短延迟保存失败，建议搭配
"files.watcherExclude"排除node_modules等目录 - macOS 使用 APFS 文件系统时，
autoSaveDelay小于200可能触发 Spotlight 实时索引争抢，表现为光标偶尔卡顿 - 如果你用 Settings Sync，确保
files.autoSaveDelay没被 sync 规则排除——它默认是同步项，但个别自定义 sync 配置可能漏掉
延迟值本身没有魔法数字，关键是匹配你的手速、项目规模和插件负载。调得太激进，反而让“自动保存”变成干扰源。
