VSCode Live Share 冲突本质是OT算法在重叠编辑区失效，导致代码静默覆盖而非生成Git冲突；需靠人为分工、禁用自动格式化、默认只读+临时授权等流程约束来防控，无法依赖自动合并。
VSCode 实时协作中代码被覆盖，不是网络问题，而是 OT 同步机制在重叠编辑区域失效了——必须靠人为干预+流程约束，不能只等自动合并。
Live Share 编辑冲突为什么总在第5–10行爆发
这不是巧合。函数签名、import 列表、对象字面量开头这几处天然具备「高编辑密度 + 低容错偏移」特征：用户 A 在 const result = calculateTotal(items); 后回车插入新行，用户 B 正好删掉上一行的 items 参数，OT 算法因位置偏移错乱，把两段操作都应用到同一行，结果变成 const result = calculateTotal();calculateTotal(items); 这类语法错误。
常见诱因包括：
- 多人同时修改同一
import块（哪怕只是加个逗号） - 在未保存状态下格式化（Prettier 触发全文件重排，与手动编辑冲突）
- 光标停在行尾或空行时，两人几乎同时按回车
Accept Both 在 Live Share 里根本不管用
Accept Both Changes 是 Git 合并编辑器的功能，只作用于 git pull 或 git merge 产生的冲突标记（），而 Live Share 的实时覆盖不生成任何 Git 冲突块——它直接改内存里的文档状态，连 Git 都不知道发生了什么。
所以你看到代码“莫名消失”或“拼接错乱”，不是 Git 拒绝合并，是 OT 已经把两个操作都落到了编辑器 buffer 里。此时：
- 别急着
git checkout -- file.ts，可能本地 buffer 和磁盘内容已不一致 - 先按
Ctrl+Z多撤几次，看能否退回未覆盖前的状态 - 如果失败，打开命令面板执行
Live Share: Show Session Logs，搜索conflict或transform failed关键词定位操作时间点
真正管用的防覆盖三招
技术上无法根除 OT 局限，但能大幅降低风险：
- 对
package.json、tsconfig.json、import区域这类高危区，约定「谁先光标进入谁负责编辑」，编辑中右上角会显示他人光标，别抢 - 禁用自动格式化（关掉
"editor.formatOnSave": false），改为手动按Shift+Alt+F，且务必确认无他人正在编辑该文件 - 开启
"liveshare.allowEditing": false默认只读，需要协同改某文件时，主机临时授予编辑权，改完立刻收回
冲突发生后第一件事不是修代码
先暂停所有输入，检查右下角状态栏是否显示 Live Share: Conflict detected（部分版本会提示）。没有提示也不代表安全——OT 冲突可能静默发生。
此时最可靠的动作链是：
- 所有人立即停止编辑该文件
- 主机执行
Live Share: End Session中断共享 - 各自运行
git status，比对git diff输出，确认哪段是真实变更、哪段是 OT 错乱产物 - 用 Git 暂存正确版本，再重新启动 Live Share
记住：Live Share 的「实时」是以牺牲最终一致性为代价换来的，越想快，越要主动让渡控制权。真正的协同效率，藏在「谁不动手」的默契里，不在「谁敲得更快」的指法中。
