VSCode无文件防写机制，“防覆盖”靠协作节奏与意图对齐；开启files.autoSave会破坏Live Share依赖的显式信号链，其中"afterDelay"最危险，"off"最安全，应禁用自动保存并以Ctrl+S作为明确协作信号。
VSCode 本身没有“文件防写”机制，也不存在能阻止你覆盖别人代码的保存锁；所谓“防止覆盖”，本质是靠协作节奏、状态可见性与保存意图对齐来规避——自动保存反而会破坏这个对齐。
为什么开启 files.autoSave 会让 Live Share 协作更危险
Live Share 的同步依赖显式操作信号（比如按键、粘贴、手动保存），而 files.autoSave 的静默触发会打乱这个信号链：
-
"afterDelay"模式（默认 1000ms）最危险：你在打字中途切走窗口，VSCode 自动保存半截代码，对方正在同一区域编辑却无任何提示 -
"onFocusChange"次之：至少你能感知“我刚离开这个文件”，但若没口头同步，对方仍可能误判你的修改完成状态 -
"off"是唯一安全基线：所有保存必须由Ctrl+S触发，天然形成“改完 → 看一眼对方光标 → 保存 → 口头确认”的协作节拍
如何真正降低保存覆盖风险
禁用自动保存只是第一步，关键在补全协作上下文：
- 在
settings.json中明确设为："files.autoSave": "off" - 同时关掉
editor.formatOnSave：格式化是独立动作，不该和“我已完成修改”这个信号绑定 - 约定团队统一用
Ctrl+S作为“本轮修改结束”的显式信号，并配合聊天工具发一句“已保存，可 review” - 启用
files.autoSaveDelay（如3000）仅作本地容灾：它不参与 Live Share 同步，只防你本地崩溃
当覆盖已经发生，怎么快速回滚
别急着重写，先还原到上一个双方都认可的状态：
- 立刻按
Ctrl+Z撤销本地最后一次保存（VSCode 会退回到上一个已同步版本） - 打开命令面板（
Ctrl+Shift+P），运行Live Share: Show Session Details，确认当前会话是否仍在活跃 - 如果对方也刚保存过，打开该文件右键 →
Open Local History，选中覆盖前的时间点还原（路径在.vscode/.history/下）
真正的风险点不在保存动作本身，而在于你和协作者对“谁改了什么、改到哪一步”的认知是否同步；VSCode 不会替你做这件事，它只忠实执行你的输入——所以每次 Ctrl+S 都该是一次有意识的协作表态，而不是下意识的手指反射。
