VSCode自动保存本身不导致代码覆盖，但会掩盖“谁改了什么”的同步信号，加剧Live Share协作冲突；其三种模式中"afterDelay"风险最高，"off"最安全，应禁用自动保存并以Ctrl+S作为明确协作信号。
VSCode 的自动保存（files.autoSave）本身不会导致“代码覆盖”，但它是多人协作中冲突感知延迟、误操作加剧的关键诱因——问题不在保存动作，而在它掩盖了“谁改了什么”这一关键同步信号。
为什么开启 files.autoSave 会让 Live Share 冲突更难察觉
Live Share 的实时编辑同步依赖用户显式行为（如按键、粘贴、保存）触发变更广播。当 files.autoSave 设为 "afterDelay" 或 "onFocusChange" 时：
- 你未主动保存，但 VSCode 在后台悄悄执行了保存 → 触发一次“静默同步”，对方可能正编辑同一区域却没收到明显提示
- 光标高亮和选区颜色仍正常显示，但文本内容已因你的自动保存被覆盖（尤其当你刚回退过修改又切走窗口）
- 对方看到的“最新版本”其实是你自动保存后的状态，而你本地视图可能还停留在旧缓存（尤其网络抖动时）
files.autoSave 的三种模式对协作的实际影响
不同设置在 Live Share 场景下表现差异极大，不是“开或关”的二选一，而是“何时由谁控制保存节奏”：
-
"off"：最安全。所有保存必须手动Ctrl+S，你会自然形成“改完 → 看一眼对方光标 → 保存 → 口头确认”的协作节拍 -
"afterDelay"：风险最高。默认 1000ms 延迟，极易在你打字中途触发保存，把半截代码推给对方，且无任何 UI 提示 -
"onFocusChange"：次高风险。切出编辑器窗口即保存，但至少你能感知到“我刚离开这个文件”，可提前口头同步
真正有效的协同保存策略：禁用自动保存 + 启用 files.autoSaveDelay 配合人工节奏
这不是倒退，而是把控制权交还给人。Live Share 本就不该模拟“单机体验”，而应强化协作意图表达：
- 在
settings.json中明确关闭："files.autoSave": "off" - 如需防丢，可加一行：
"files.autoSaveDelay": 3000（仅作本地容灾，不参与 Live Share 同步） - 约定团队统一使用
Ctrl+S作为“我已完成本轮修改，请检查”的信号，配合内置聊天发送“已保存，可 review” - 禁用
editor.formatOnSave—— 格式化是独立操作，不应绑定在保存这个协作临界点上
当覆盖已发生：快速回滚并重建同步状态
如果你发现刚保存的内容被对方“覆盖”（例如你删了一行，对方却保留了它），不要直接重写：
- 先按
Ctrl+Z撤销本地最后一次保存（VSCode 会还原到上一个已同步状态） - 打开命令面板
Ctrl+Shift+P，运行Live Share: Show Session Details，确认当前共享会话 ID 和连接状态 - 点击编辑器右上角的“同步状态”图标（两个箭头循环），选择
Refresh from Shared Server，强制拉取对方最新快照 - 对比差异后，再决定是合并还是协商重做 —— 此时双方都清楚“哪次保存生效了”
自动保存开关只是表象，核心在于是否让每次保存成为一次可感知、可协商的协作事件。多人编辑时，延迟 0.5 秒的手动保存，比毫秒级自动同步更能守住代码一致性底线。
