长文本编辑时禁用onFocusChange，改用afterDelay并设5000ms以上延迟，可避免点击侧边栏、终端等操作误触发保存导致JSON缺逗号、Markdown错位等问题；同时建议关闭code-runner.saveFileBeforeRun及语言专属trimTrailingWhitespace。
长文本编辑时，VSCode 的自动保存必须关掉 onFocusChange，改用 afterDelay 并拉长延迟，否则极易误触发保存、打断输入节奏。
为什么长文本编辑不能用 onFocusChange
你在写 Markdown、JSON 配置、SQL 脚本或大段注释时，频繁点击侧边栏、大纲视图、终端或 Git 面板——这些操作都会让编辑器“失去焦点”，一旦启用了 onFocusChange，VSCode 会立刻把当前未完成的半截文本写入磁盘。结果可能是：JSON 少了个逗号就保存了，Markdown 表格对不齐就落盘了，甚至光标还在中间、你只是想查个变量名，文件却已损坏。
这不是 bug，是设计逻辑：VSCode 把“焦点离开”当作“编辑意图结束”的信号，但长文本写作恰恰需要多点协同操作。
- 禁用
onFocusChange和onWindowChange，二者在长文本场景下都太激进 - 确认当前
files.autoSave值不是"onFocusChange"（可在设置搜索框输files.autoSave直接查看） - 若已在
settings.json中硬编码该值，需手动删掉或改成"afterDelay"
怎么配 afterDelay 才适合长文本
afterDelay 是唯一可控的折中方案：它只在你真正停顿后才保存，但默认 1000ms（1 秒）对长文本仍太短——敲两行字、换行、加个缩进，就可能触发保存。
- 把
files.autoSaveDelay设为5000（5 秒）或更高，比如10000（10 秒） - 这个值不是“最长等待时间”，而是“最后输入后静默多久才存”；只要你在 5 秒内继续打字，计时就重置
- 对 >1MB 的日志片段或 SQL 导出内容，建议设到
15000，避免编辑器反复序列化大字符串 - 可在用户设置（全局）或工作区设置（仅当前项目）中配置，后者优先级更高
code-runner.saveFileBeforeRun 与长文本的冲突
如果你常用 Code Runner 运行脚本（尤其是 Python/Shell），它的 saveFileBeforeRun 默认为 true，会强制在每次点击 ▶️ 前保存当前文件——这和 afterDelay 叠加后，可能出现“刚打完一行就运行、结果保存了半截代码”的情况。
- 长文本写作期间，建议临时关闭：
"code-runner.saveFileBeforeRun": false - 或者干脆不用 Code Runner 运行长文本类文件（如 .md/.log/.sql），改用终端手动执行
- 注意：关掉它不等于不保存，只是把保存动作交还给你自己按 Ctrl+S 控制
额外提醒：别忽略 files.trimTrailingWhitespace
长文本里空格和换行很敏感，比如 YAML 缩进、SQL 换行注释、正则表达式中的空白字符。VSCode 默认开启 files.trimTrailingWhitespace，每次保存都会抹掉行尾空格——这可能导致格式错乱或语法报错。
- 对 Markdown、YAML、TOML、.env 等文件类型，建议在语言专属设置中关掉它：
"[markdown]": { "files.trimTrailingWhitespace": false }"[yaml]": { "files.trimTrailingWhitespace": false }- 不要全局关，否则普通代码文件会积累无意义空格
长文本编辑的核心矛盾从来不是“要不要保存”，而是“什么时候才算写完了”。VSCode 不会替你判断语义完整性，所有自动机制都是基于行为信号的粗略猜测——所以最稳的方式，是把保存节奏收回到自己手上，用延迟代替即时，用显式代替隐式。
