vscode 的 autosave 无周期性定时保存功能，仅 afterdelay 模式支持输入停顿后延迟保存，需先设 files.autosave 为 afterdelay，再配置 files.autosavedelay（最小100ms）。
VSCode 的 autoSave 默认不按时间间隔触发
VSCode 的 autoSave 功能根本没有「多少秒保存一次」的配置项。它只支持三种触发模式：off、afterDelay、onFocusChange、onWindowChange。所谓“时间间隔”，仅在 afterDelay 模式下生效，且是**从用户停止输入起倒计时**，不是周期性轮询保存。
常见错误现象：有人在设置里搜 autoSaveDelay 却找不到，或误以为设了 1000 就等于“每秒保存”，结果发现改完代码等半天也没存——因为没失焦、没切窗口，且还没过延迟阈值。
-
afterDelay模式下，延迟由files.autoSaveDelay控制（单位毫秒），默认 1000，最小可设 100 - 必须先在设置中把
files.autoSave改为afterDelay，files.autoSaveDelay才生效 - 该延迟只对当前编辑的文件有效；切换标签页或失去焦点会立即保存，不等延迟结束
如何正确配置「输入停顿后自动保存」
这是最接近“按时间间隔保存”的实际做法，本质是控制响应惰性，而非定时任务。
使用场景：避免频繁保存干扰 Git diff，又不想手动按 Ctrl+S；适合写 Markdown、JSON 或配置类文件。
- 打开设置（
Ctrl+,），搜索files.autoSave，选afterDelay - 再搜索
files.autoSaveDelay，填入数字（如800） - 注意：这个值不能低于
100，设成0会被忽略，仍按默认1000处理 - 如果同时启用了格式化（如 Prettier），
formatOnSave会和autoSave协同：保存动作触发格式化，再写回磁盘
为什么不用扩展模拟「定时保存」
确实有扩展（如 Auto Save Plus）声称支持“每隔 X 秒保存”，但它们本质是用定时器调用 VSCode 的保存 API。这会带来几个现实问题：
- 未修改的文件也会被“重写”，导致文件修改时间戳刷新，干扰
git status和构建工具的增量判断 - 正在输入中途强制保存，可能存下语法不全的代码（比如刚敲完
if (就被保存），破坏开发节奏 - 与原生
autoSave冲突，容易出现重复保存、保存失败却无提示等问题 - VSCode 1.84+ 已限制扩展对核心保存流程的干预，部分定时类扩展在新版本中失效或报错
command 'workbench.action.files.save' not found
真正影响保存行为的隐藏因素
很多人调了 autoSaveDelay 还是感觉“没反应”，往往卡在这些非显性配置上：
-
files.enableTrash关闭时，某些系统（尤其是 Windows）删除临时文件失败会导致保存挂起，看似“没保存” -
files.autoSave被工作区设置（.vscode/settings.json）覆盖，优先级高于用户全局设置 - 远程开发（SSH/Containers）场景下，
files.autoSaveDelay依然生效，但网络延迟可能导致保存反馈变慢，不是没保存，是 UI 没及时更新状态 - 大文件（>50MB）默认被 VSCode 排除在
autoSave外，不会触发任何延迟保存逻辑
延迟值调太小（比如 200）几乎没意义——编辑器本身处理输入、语法高亮、语义分析就有毫秒级延迟，人眼根本感知不到差异，反而增加磁盘写入压力。
