live share不是“装了就能用”的功能，必须完成插件手动安装并重启vs code、登录microsoft或github账户、设置liveshare.allowexternalparticipants为true三步，否则90%连接失败和编辑不同步问题将发生。
Live Share 不是“开启就能用”的功能，它依赖明确的权限配置、网络放行和协作角色分工；没做对这三步，90% 的连接失败和编辑不同步问题都出在这里。
Live Share 插件安装与首次登录必须完成这三件事
插件已从 VS Code 1.118 起移出默认捆绑，必须手动安装。只装 Live Share 就够了，Live Share Extension Pack 是可选集合，不装不影响核心功能。
- 安装后必须重启 VS Code（不是重载窗口），否则状态栏不会出现
Share按钮 - 首次启动会话前，必须登录 Microsoft 或 GitHub 账户——这是生成加密链接和权限控制的基础，离线模式无法绕过
- 在设置中搜索
liveshare.allowExternalParticipants，设为true；否则外部协作者点击链接后会卡在“正在连接”，无报错提示
共享会话启动后，链接无效或“Failed to start collaboration session”怎么排查
这个错误基本和插件无关，而是网络层拦截。VS Code 启动 Live Share 时会尝试连接 vscode.liveshare.com 和中继用的 wss://*.vscode.liveshare.com，企业防火墙、代理或广告屏蔽插件（如 uBlock Origin）常静默丢弃这些请求。
- 先在命令面板（
Ctrl+Shift+P）运行Live Share: Export Logs，检查日志里是否出现Failed to connect to relay或STUN request timed out - 临时禁用所有浏览器扩展，尤其是广告/脚本拦截类；协作者端也要关掉，它们会拦截邀请链接弹出的权限确认窗
- 若在公司内网，需 IT 放行
stun:global.stun.twilio.com（用于 P2P 打洞）和wss://*.vscode.liveshare.com（中继通信） - 紧急可用：在设置中搜
liveshare.relay，改为https模式，强制走 HTTPS 中继（牺牲一点延迟，但绕过大部分网络限制）
协作者加入后光标不动、编辑无响应，其实是权限或路径没对齐
Live Share 默认赋予 Edit 权限，但调试和终端操作需额外显式授权；更常见的是本地环境差异导致语言服务“失联”，表现为 IntelliSense 不工作、断点灰色、跳转失效。
- 主持人启动调试前，确认
launch.json中的program路径使用${workspaceFolder}等相对变量，而非绝对路径（如C:\project\src\index.js） - 协作者端若看不到源码映射（显示
VMxxx而非真实文件名），检查主持人是否启用了sourceMaps: true且生成了.map文件 - 终端共享后，协作者输入命令实际在主持人机器执行；如需各自运行本地命令（比如
npm run dev），应主动点击状态栏Live Share→Stop Sharing Terminal - 敏感文件（如
.env、secrets.json）不会自动隐藏，必须提前关闭对应标签页，或用.vsls.json配置ignore列表
Live Share 和 Git 的边界必须划清，否则会误以为“协作成功”
它不提交、不拉取、不显示 Git 状态栏，所有分支切换、git commit、git push 都是各自本地行为。你看到协作者改了某行，不代表那行已进仓库——这只是实时编辑同步，不是代码同步。
- 协作结束前，务必提醒所有人手动
git add && git commit，否则退出会话后修改就丢了 - 不要用
Share Workspace共享含node_modules或大型二进制文件的项目，会拖慢加入速度甚至失败；应只共享src、lib等源码目录 - 调试时协作者能看变量、设断点，但只有主持人能点
F5启动或F8继续；协作者右键变量选Copy Value是安全的，但执行Debug Console表达式仍受限于主持人环境
最易被忽略的一点：Live Share 的“同步”本质是操作广播 + OT（Operational Transformation）合并，不是文件覆盖。这意味着如果两人同时在行尾插入字符，系统能正确合并，但若一人删整行、另一人正在该行中间编辑，可能触发冲突提示——这不是 bug，是协同编辑的固有约束，得靠沟通避开高频冲突区。
