Live Share 实时协作结对编程依赖网络穿透、权限边界、调试上下文同步三根支柱；默认仅开放文件编辑权限，debug/terminal/server需主机手动启用，且调试变量等上下文需主机配置兼容路径才能同步。
VSCode 实时协作结对编程，核心就看 Live Share 能不能稳住——它不是“加个插件就能一起敲”，而是依赖网络穿透、权限边界、调试上下文同步这三根支柱。配错任意一个，就会出现“看到对方光标但看不到变量值”“能共享终端却无法打断点”这类典型失步现象。
Live Share 主机与参与者的权限差异
很多人以为加入会话后双方权限对等，实际不是：Live Share 默认只授予“查看+编辑文件”权限，debug、terminal、server 这三类高危能力必须手动开启，且仅主机可主动启用。
- 主机侧需在会话启动后，点击状态栏
Live Share图标 → “Share Debug Session” 或 “Share Terminal” 才能释放对应能力 - 参与者看到的调试面板（Variables/Watch/Calls）是主机进程的实时镜像，但断点设置、单步执行操作仍由主机控制；参与者只能请求暂停或触发“Request Debug Access”临时接管
- 若主机未开启
Share Server，参与者访问http://localhost:3000会失败——因为这个地址指向的是主机本地回环，不是共享服务端口
vscode-live-server 与 Live Share 的端口协同机制
vscode-live-server 在 Live Share 会话中不是简单地把端口“转发”出去，而是通过 LiveShareHelper.ts 注入一层代理路由，把所有参与者请求重定向到主机的 live-server 实例。这意味着：
- 参与者浏览器访问的 URL 是
https://<host-id>.live-share.vsengsaas.visualstudio.com:3000/</host-id>这类网关地址，而非localhost - 主机上
liveServer.settings.port配置只影响本地开发体验；真正对外暴露的端口由 Live Share 网关动态分配，不可手动指定 - 若主机设置了
liveServer.settings.host: "127.0.0.1"，会导致共享失败——必须设为"0.0.0.0"或留空，否则服务器绑定在回环地址，网关无法代理
调试上下文不同步的常见诱因
结对时最常遇到“我能看到源码，但 Variables 面板为空”，根本原因往往不在插件本身，而在调试器启动方式：
- 用
F5启动调试时，VSCode 默认使用当前工作区的launch.json；但 Live Share 会话中，参与者没有本地运行环境，必须依赖主机的调试配置和进程上下文 - 如果主机用的是
node调试，但launch.json中runtimeExecutable指向了绝对路径（如/usr/local/bin/node），而参与者系统路径不同，Variables 就会加载失败 - 推荐做法：主机配置
launch.json时，runtimeExecutable留空，让 VSCode 自动查找 PATH 中的 node；同时确保env字段不包含硬编码路径（如NODE_PATH）
真正卡住人的从来不是“怎么开共享”，而是“为什么共享后某些功能失效”。Live Share 的能力是按需注入的，不是全有或全无；每个开关背后都对应一个独立的 IPC 通道和安全策略，漏掉任何一个，协作流就会在某个环节静默断开。
