Live Share 连不上因网络策略拦截 WebSocket（wss://prod.liveshare.vsengsaas.visualstudio.com），非插件缺失；需确认双方插件版本≥1.0.5800、开放域名及端口、禁用代理/杀软扫描，且勿误配serviceUrl。
Live Share 为什么连不上，提示 Failed to start collaboration session
根本原因通常是网络策略或代理拦截了 Live Share 的 WebSocket 连接（默认走 wss://prod.liveshare.vsengsaas.visualstudio.com），不是你本地 VSCode 没装插件，也不是对方没点“开始协作”。
实操建议：
- 先确认双方都安装了官方
Live Share插件（ID：ms-vsliveshare.vsliveshare），且版本 ≥ 1.0.5800 —— 老版本在新版 VSCode 上会静默失败 - 关闭公司防火墙、企业级代理（如 Zscaler、Netskope）、或临时禁用杀毒软件的“网络流量扫描”功能；家用路由器一般没问题
- 如果公司网络严格，让 IT 开放以下域名和端口：
prod.liveshare.vsengsaas.visualstudio.com（443）、vscode.dev（443） - 不要手动改
liveshare.serviceUrl配置项，它只对私有部署有效，填错反而导致连接失败
共享时对方看不到我的终端 / 终端命令不同步
Live Share 默认不共享终端（Terminal）—— 这是设计行为，不是 bug。终端进程运行在各自本地系统上，强行同步会引发权限、路径、环境变量冲突。
实操建议：
- 需要共看终端输出？用
Share Terminal功能（右键终端面板 →Share Terminal），但仅共享只读输出，不能输入 - 想一起敲命令？推荐用
Remote - SSH+ 共享同一台服务器，或改用tmux/screen+reptyr等方案，Live Share 不负责这个场景 - 调试器（Debugger）和断点是实时同步的，但
launch.json中的env和cwd仍使用各自本地配置，别指望对方能直接npm run dev成功
怎么限制协作权限，比如禁止对方修改文件？
Live Share 提供三种协作角色：Guest（默认可编辑）、ReadOnly Guest、Presenter。但“只读”不是靠插件开关控制，而是由 Host 主动降权发起。
实操建议：
- 发起协作时，在弹出的分享面板里，点击
Guest permissions下拉菜单，选Read only—— 这样对方打开文件只能查看、不能保存 - 已进入协作后想改权限？Host 在状态栏点击
Live Share图标 →Change guest permissions→ 切换即可 - 注意：
Read only不影响对方运行代码、启动调试、查看终端输出，只锁住编辑和保存动作；想彻底隔离执行环境，得用容器或远程开发
为什么对方能看见我所有打开的文件，包括未保存的 Untitled-1？
Live Share 共享的是“工作区视图状态”，不是文件系统。只要你在编辑器里打开了某个标签页（哪怕只是空的 Untitled-1），就会被同步过去——这是为了还原协作上下文，但容易暴露临时笔记或敏感草稿。
实操建议：
- 协作前主动关闭无关标签页，尤其是带密码、token、内部路径的临时文件
- 用
File → Close All Editors快速清理，或按Ctrl+K W（Windows/Linux）/Cmd+K W（macOS）关闭当前工作区全部标签 - VSCode 设置里关不掉这个行为，
"liveshare.hideUnsharedFiles"只影响未加入工作区的文件，对已打开的Untitled无效
Live Share 的核心约束很实在：它不跨系统执行、不替代远程开发、不隐藏编辑器状态。真正容易被忽略的，是它把“打开即可见”当作协作前提——这在小团队快速对齐时很高效，但在涉及敏感上下文时，得靠人手动清理，而不是指望配置项兜底。
