远程团队协作需先通过Remote-SSH成功连接服务器并加载远程工作区，再启动Live Share；插件、调试配置、端口共享及工作区设置均须部署于remote端并纳入版本控制。
远程团队协作不是靠“装一堆插件”就能跑起来的，关键在于 Remote-SSH 和 Live Share 的职责分清、加载顺序正确、权限边界明确。否则协作者看到的是空文件夹、终端打不开、调试器报错找不到 program 路径——这些都不是配置没写对，而是环境没就绪。
Remote-SSH 必须先连通，Live Share 才能共享真实项目
Live Share 不是独立远程工具，它依赖当前 VS Code 已加载的工作区上下文。如果你本地打开一个空文件夹再点 Live Share: Start Collaboration Session，生成的链接只会让协作者看到你本地的空白目录。
- 必须先用
Remote-SSH: Connect to Host成功连接目标服务器，并在资源管理器中确认显示的是远程路径（如/home/user/project） - 左下角状态栏出现绿色 SSH 图标，且已打开至少一个远程文件，才算准备就绪
- 此时再启动 Live Share，协作者加入后看到的才是运行在远程服务器上的完整代码树、已开启的终端和断点
远程环境下插件必须装在 remote 端，否则协作者看不到
VS Code 的 Remote-SSH 会把扩展拆成本地（local）和远程（remote）两部分加载。Live Share 只同步 remote 端已启用的功能，本地安装的插件对协作者完全不可见。
- ESLint、Prettier、GitLens 等需读取项目配置的插件，必须在远程服务器上安装：点击扩展面板右下角弹出的
Install on SSH: xxx提示，或手动切换到 remote 标签页安装 - 调试器（如
Python或Node.js）扩展也必须装在 remote 端，且launch.json中的program路径要用${workspaceFolder}，不能写死本地路径 - 像
Remote-Containers这类扩展，其配置（.devcontainer/devcontainer.json）必须存在于远程项目根目录，Live Share 才能继承容器环境
共享终端和本地服务要提前设好权限，别等协作者输 sudo 密码
Live Share 共享的终端默认以当前远程用户身份运行，不转发 sudo 权限。协作者输入密码会卡住，甚至触发 SSH 会话中断。
- 需要执行特权操作时，提前写好封装脚本（如
./scripts/restart-server.sh），并赋予可执行权限：chmod +x ./scripts/restart-server.sh - 通过
Live Share: Share Terminal共享终端后，直接运行该脚本即可，避免交互式提权 - 若需共享本地端口服务（如开发服务器监听
:3000），启用"liveshare.shareServer": true，并在settings.json中显式声明端口："liveshare.serverPorts": [3000]
工作区配置要提交到仓库，别让新人自己猜
团队协作效率掉坑，90% 发生在新人第一次打开项目时。靠口头说“记得装 Prettier”“tabSize 设成 2”不如直接把规则固化进配置文件。
- 项目根目录放
.vscode/settings.json，包含"editor.formatOnSave": true、"editor.tabSize": 2等基础设置，提交到 Git - 推荐扩展统一写在
.vscode/extensions.json或多根工作区文件（team-workspace.code-workspace）的extensions.recommendations字段里 - 远程开发配置（如
.devcontainer/devcontainer.json）也必须进版本库，确保所有成员用同一镜像、同一 Node.js 版本、同一预装扩展集
最容易被忽略的其实是网络稳定性对协作链路的影响：Remote-SSH 连接一旦抖动断开，Live Share 会话自动终止，但 VS Code 不一定立刻提示。建议团队约定一个简单心跳机制，比如共享终端里运行 watch -n 5 'date'，双方都能看到时间更新，就是链路还活着。
