Live Share 仅实现实时协同编辑与调试，不替代 Git；需手动安装插件、登录微软账户、开启外部参与权限；同步编辑器视图、终端、调试状态等，不同步配置、插件、文件系统变更。
Live Share 不能替代 Git 协作，它解决的是“此刻一起看同一段代码、一起调试”的实时协同问题；一旦退出会话，所有共享状态立即消失，不会留下任何远程分支或提交记录。
如何安装并启动 Live Share 会话
Live Share 插件已不再默认内置，必须手动安装：打开扩展面板（Ctrl+Shift+X），搜索 Live Share，选择 Microsoft 官方发布的 Live Share 扩展并安装。重启 VSCode 后，底部状态栏会出现 Share 按钮。
点击该按钮即启动会话，VSCode 会自动生成一个加密的邀请链接。注意：首次使用需登录微软账户（支持 GitHub 账户绑定），且必须开启 Allow participants to join from outside your organization（在设置中搜索 liveshare.allowExternalParticipants 并设为 true），否则外部协作者无法加入。
- 邀请链接有效期默认 7 天，但只要主机不关闭会话，协作者可随时加入/退出
- 如果点击
Share后无反应或提示“Failed to start collaboration session”，大概率是防火墙或公司代理拦截了vscode.liveshare.com域名 - 不建议用
Share Workspace（共享整个工作区），尤其当项目含node_modules或大型二进制文件时——这会显著拖慢加入速度甚至失败
协作时哪些内容会被同步，哪些不会
Live Share 默认只同步编辑器视图、光标位置、终端（仅当前激活的终端）、调试状态（断点、变量、调用栈）和部分语言服务响应（如 IntelliSense 补全）。它不会同步你的本地配置文件（settings.json、keybindings.json）、插件、用户片段（snippets）或全局安装的 CLI 工具路径。
- 协作者看到的代码高亮、缩进、字体完全取决于他们自己的主题和设置，不是你的
- 你运行
npm run dev启动的本地开发服务器，协作者无法直接访问其http://localhost:3000——除非你额外启用Live Share: Start Server并共享端口（需主机明确授权） -
Debug状态同步有延迟：协作者看到的变量值可能比你本地滞后 1–2 秒，复杂对象展开时容易卡顿
常见错误：Unable to connect to the host 怎么办
这个错误几乎都源于网络层而非插件本身。Live Share 使用 WebRTC 直连，若直连失败，会尝试通过 Microsoft 中继服务器，但中继对大流量（如共享终端输出）支持有限。
- 先检查协作者是否点击了链接后弹出的权限确认弹窗（浏览器里常被自动屏蔽）
- 主机和协作者都禁用广告屏蔽插件（如 uBlock Origin），它们常误杀
liveshare的 WebSocket 连接 - 若在企业内网，联系 IT 确认是否放行
wss://*.vscode.liveshare.com和stun:global.stun.twilio.com - 临时方案：主机在命令面板（
Ctrl+Shift+P）执行Live Share: Export Logs，把生成的.zip日志发给协作者，里面包含真实的连接失败原因（比如ICE connection failed）
为什么改了代码，协作者看不到实时更新
这不是 Bug，而是设计使然：Live Share 只同步编辑器内的“文本变更”，不监听文件系统事件。如果你在终端里执行 git checkout、npm install 或其他命令导致文件被外部修改，协作者的编辑器不会自动刷新。
- 手动触发刷新：协作者按
Ctrl+R（Windows/Linux）或Cmd+R（macOS）重载窗口，或右键文件 →Reopen Editor - 更稳妥的做法是：所有文件变更（包括 git 切换、依赖安装）都在主机上操作，协作者专注阅读、评论、调试，避免两边同时改同一文件
- 特别注意
.env、package-lock.json等自动生成文件——它们被修改后不会触发 Live Share 同步，但可能让协作者的 IntelliSense 显示错误类型
真正难处理的从来不是怎么点开共享按钮，而是谁该控制终端、谁来触发构建、冲突时以谁的本地状态为准——这些得靠人定规则，Live Share 不帮你做决定。
