成员点开邀请链接无法加入，需检查三点：未登录Microsoft/GitHub账户、本地未安装Live Share扩展、主机网络拦截wss://*.vsliveshare.com中继连接。
生成邀请链接后，成员点开就进不来？检查这三点
VSCode Live Share 的邀请链接本身是有效的，但成员无法加入最常见的原因是权限或环境缺失。不是链接失效，而是协作链路没打通。
-
liveshare.allowAnonymousGuests设为false时，未登录 Microsoft/GitHub 账户的访客会被直接拒绝，页面可能只显示空白或“Access denied” - 成员本地没装 Live Share 扩展：浏览器点击链接后会跳转 VS Code，但若扩展未安装或未完成初始化（尤其首次启动），连接会卡在“Connecting…”状态
- 主机端网络策略拦截了中继连接：企业防火墙或代理常屏蔽
wss://*.vsliveshare.com域名，此时访客控制台报错WebSocket connection to 'wss://...' failed
终端里用 CLI 生成链接，和 GUI 点击有啥区别？
本质一样，都是调用同一套 Live Share 后端服务，但 CLI 更可控、更适合自动化场景。
- GUI 方式（
Live Share: Start Collaboration Session）会在状态栏显示链接，适合快速手动分享 - CLI 方式需先全局安装：
npm install -g @vsliveshare/cli，然后运行：npx @vsliveshare/cli start，输出含sessionId和完整 URL，方便脚本捕获或写入 CI 日志 - CLI 不依赖 VS Code UI 状态，即使编辑器崩溃或未完全加载，只要后台服务运行，仍可生成有效链接
为什么访客能看代码却不能输命令到终端？
终端交互默认关闭，必须显式启用，且权限需匹配。这不是 bug，是安全默认行为。
- 主机需在
settings.json中开启："liveshare.terminalSharing": true - 仅开启还不够，还要确认会话配置里终端权限没被锁死 —— 检查
liveshare.accessControl.terminal是否设为"write"（而非"read"或缺失） - 访客端如果开了多个终端实例，只有主机主动共享的那个（比如
bash #1）才可交互；其他终端标签页仍是本地独占
邀请链接有效期和安全性怎么管？
链接本身没有硬性过期时间，但实际有效性取决于会话生命周期和身份验证策略。
- 会话不结束，链接就一直有效 —— 主机关掉 VS Code 或执行
Live Share: End Session后，所有访客立即断连 - 启用
"liveshare.authentication.enabled": true后，链接变成“一次一验”，访客每次点击都要重新登录，防止链接泄露后被复用 - 别把链接发到公开群或 commit 里：它虽带 JWT token，但本质仍是 bearer token，中间人截获即可冒用
真正容易被忽略的是终端权限的双重控制：既要在全局设置里打开 liveshare.terminalSharing，又得在访问控制策略里明确授予 terminal 的 write 权限 —— 少一层，访客就只能看，不能敲。
