Live Share不是装了就能用，需双方登录同一账户体系、网络放行域名、VS Code≥1.80；终端默认不共享，调试依赖本地配置，权限控制须主机主动设置只读。
Live Share 不是“装了就能用”的功能，它对双方环境、网络策略和操作顺序都有明确依赖。多数连接失败、权限异常或终端不同步问题，根源不在插件本身，而在登录状态、共享粒度或网络拦截。
Live Share 启动失败或点击 Share 无反应
这通常不是插件没装好，而是身份验证或网络策略卡住了第一步。
- 必须先执行
Live Share: Sign in命令（Ctrl+Shift+P 输入），用 Microsoft 或 GitHub 账户完成授权；仅安装插件不登录，Share按钮会静默失效 - 公司网络下常见失败：防火墙或代理（如 Zscaler）拦截了
prod.liveshare.vsengsaas.visualstudio.com；可临时禁用杀软的“网络扫描”，或让 IT 放行该域名 + 443 端口 - VS Code 版本低于 1.80 时，TLS 1.3 握手可能失败；确保双方都用 Stable 渠道，且版本 ≥ 1.80
- 对方点击链接后卡在 “Waiting for guest…”？检查其是否也完成了登录——不能你用 GitHub 登录、对方用 Outlook 登录，跨账户体系可能被策略拒绝
协作者看不到终端 / 终端命令不同步
Live Share 默认不共享终端，这是设计使然，不是 bug。终端进程始终运行在各自本地系统上，强行同步会引发路径、权限、环境变量冲突。
- 需要共看输出？右键终端面板 →
Share Terminal，但仅提供只读输出，无法输入 - 需要一起敲命令？这不是 Live Share 的职责，应改用
Remote - SSH连同一台服务器，或用tmux+reptyr方案 - 共享终端 ≠ 共享执行环境：你本地
npm run dev启动的服务，对方无法直接访问http://localhost:3000，除非你额外启用Live Share: Start Server并显式共享端口
调试不同步、断点不触发、变量值滞后
调试状态虽实时同步，但底层执行仍完全依赖各自本地配置，路径、环境、Node.js 版本差一点就可能失败。
-
launch.json中的program、env、cwd全部按被邀请方本地路径解析，不是你的；务必用${workspaceFolder}替代绝对路径 - 双方必须安装并启用对应语言的调试器扩展（如
ms-python.python或ms-vscode.js-debug），否则断点灰掉 - 变量值有 1–2 秒延迟，复杂对象展开易卡顿；这不是网络问题，是序列化开销导致，避免在调试中频繁展开嵌套很深的对象
- 若断点始终不命中，优先检查 Node.js 版本是否一致（尤其 v18.x 和 v20.x 之间存在
inspector协议差异）
如何真正限制协作者修改代码或执行命令
权限控制不是靠“关掉某个开关”，而是由 Host 主动发起降权，且粒度有限。
- 发起会话时，在弹出面板中点击
Guest permissions下拉菜单，选Read only；已加入后可点击状态栏Live Share图标 →Change guest permissions切换 - “只读”只锁住编辑和保存动作，不影响运行代码、启动调试、查看终端输出；想彻底隔离执行环境，得用容器或远程开发
- Terminal 权限一旦开启，协作者可执行任意命令（包括
rm -rf）；生产环境共享务必取消勾选Terminal模块 - 敏感文件（如
.env、secrets.json）不会被传输，Live Share 只同步编辑意图，不传文件内容
最常被忽略的是：Live Share 不监听文件系统变化。你 git checkout 切分支、npm install 装新包、甚至改了 .gitignore，这些变更都不会自动同步给协作者——他们看到的仍是共享那一刻的工作区快照。
