能一起用，且是最稳组合：Host先通过Remote-SSH连入远程服务器，在该远程VS Code实例中启动Live Share会话，使协作者共享服务器工作区而非本地路径。
Live Share 不是远程开发方案，而是实时协作方案；Remote-SSH 连上去的是你自己的独立会话，别人连的是另一个——那叫“并行开发”，不是结对。
Live Share 和 Remote-SSH 能不能一起用？
能，而且这是最稳的组合：Host 先用 Remote-SSH 连到服务器，再在那个远程 VS Code 实例里点 Live Share: Start Collaboration Session。这样协作者共享的是服务器上的工作区，不是本地磁盘路径。
- Host 的
vscode-server必须是 VS Code 1.80+，Live Share 后端服务才默认启用 - 服务器防火墙要放行 WebSocket（默认走 443/80），否则 fallback 到微软中继，延迟明显升高
- 别在 Host 上把
security.workspace.trust.enabled设为false，否则 Guest 强制进受限模式，终端和调试全禁用
为什么 Guest 加不进调试或看不到某些文件？
常见原因就两个：.vsls.json 限制太严，或 Host 没登录/没配好 launch.json。
-
.vsls.json里如果写了"debugging": false，Guest 就没法附加调试器，连断点都设不了 - Guest 加入时不会触发 Host 的
preLaunchTask或postStartCommand，所以像自动构建、依赖安装这类动作得 Host 手动先跑完 - Guest 看不到 Host 的未保存临时文件（比如
untitled-1），也看不到被.vsls.json的excludedFiles显式排除的路径
共享终端和本地服务时容易踩哪些坑？
共享终端默认是读写模式，但共享端口映射有隐含规则——它只转发 TCP 流量，不转发 UDP，也不支持 Unix domain socket。
- Host 共享端口
3000，Guest 访问http://localhost:3000是通的；但如果 Guest 本机3000已被占用，Live Share 会自动 fallback 到下一个空闲端口（比如3001），但不会通知 Guest - 共享终端里执行
npm run dev启的服务，若监听127.0.0.1:3000，Guest 仍无法访问——必须改成0.0.0.0:3000或:::3000 - Guest 无法通过共享终端执行 Host 的本地任务（如
tasks.json定义的构建命令），只能运行基础 shell 命令
真正结对的关键不在“连得上”，而在“权限配得准”：Host 得清楚哪些能力该开、哪些该锁，Guest 得知道哪些操作是本地生效、哪些只是镜像——不然一边改代码一边等 Git push，那就又退回传统协作了。
