vscode需依赖live share插件实现多端实时协作。live share支持同步编辑、调试、终端共享，协作者通过加密链接加入，无需配置环境；remote-ssh等仅支持单人远程开发，非协作方案。
VSCode 本身不内置多端实时协作能力，必须配合 Live Share 才能实现真正的多人同步编辑、调试、终端共享；Remote - SSH / Containers / WSL 只解决“单人远程开发”，不是协作方案。
Live Share 是唯一开箱即用的多端协作方案
Remote - SSH 连上去的是你一个人的会话，别人连的是另一个独立实例——这叫“远程开发”，不是“协作”。Live Share 才是微软官方提供的实时协同插件，它让一名开发者（Host）共享当前工作区，其他人（Guest）以只读或读写权限加入，所有操作毫秒级同步。
- 安装
Live Share扩展后，点击状态栏按钮或执行Live Share: Start Collaboration Session即可发起 - 生成的链接带一次性加密 token，过期自动失效，不暴露主机文件系统路径
- 协作者无需提前安装相同扩展、配置相同环境，Host 的语言服务、调试器、终端命令都可直接复用
- 注意：Guest 无法看到 Host 的未保存临时文件（如 untitled-1），也无法触发 Host 的本地任务（如 launch.json 中的 preLaunchTask）
Remote - SSH 不能直接用于协作，但可作为 Live Share 的底层支撑
如果你的团队习惯用 SSH 连到同一台服务器，再各自开 VSCode，那其实只是“并行开发”，不是协作。真正协作时，Live Share 仍需一个稳定 Host 环境——这个 Host 完全可以运行在远程服务器上（比如通过 Remote - SSH 连入后启动 Live Share），此时：
- Host 的
vscode-server必须支持 Live Share 后端服务（VSCode 1.80+ 默认启用） - 远程服务器需开放 WebSocket 连接（默认走
443或80，若被防火墙拦截，Live Share 会 fallback 到中继服务器） - 不要在 Host 上启用
security.workspace.trust.enabled并设为 false，否则 Guest 加入时会被强制进入受限模式，无法执行终端/调试 - Host 的
.vsls.json可显式控制共享能力，例如禁用"debugging": false防止生产环境被远程断点干扰
Dev Container + Live Share 组合最稳妥，但需注意镜像兼容性
用 devcontainer.json 定义的容器环境，配合 Live Share，能让协作者“零配置”接入统一工具链。但容易忽略两点：
- Live Share 不会自动重建容器——Host 必须先通过
Remote-Containers: Reopen in Container启动好容器，再点 Live Share 启动按钮 - Guest 加入后，
postCreateCommand和postStartCommand不会重复执行；但postAttachCommand会在每个 Guest 首次连接时运行一次（可能引发并发 npm install 冲突） - 如果容器内用了非标准端口映射（如
ports字段没写进devcontainer.json），Guest 将无法访问 Host 转发的forwardPorts服务 - 某些扩展（如
ms-python.python）在 Guest 端可能因缺少容器内 Python 解释器路径而报错，建议 Host 在devcontainer.json中明确指定"python.defaultInterpreterPath"
协作中最容易被忽略的，是权限粒度和上下文隔离：Live Share 共享的是“当前打开的文件夹+已加载的扩展状态”，而不是整个远程用户家目录；但如果你在 Host 上打开了多个根目录（比如用多根工作区），Guest 默认只能看到 Host 主活动窗口的那个文件夹——想共享全部，得手动在 .vsls.json 里配置 "sharedFolders" 数组。
