Live Share是当前最稳定、兼容性最好、权限控制最清晰的VSCode实时协作方案，必须统一配置三项工作区setting：liveshare.featureSet设为"stable"、liveshare.presence设为true、liveshare.shareServerProcess设为false。
VSCode 本身不提供原生实时协作编辑（如多人光标同步、实时变更广播），所谓“实时协作”必须依赖插件实现，且团队落地成败关键不在功能开关，而在配置一致性与行为约束。直接上结论：用 Live Share 是当前最稳定、兼容性最好、权限控制最清晰的方案；GitHub Codespaces 或 Dev Containers 适合远程统一环境但不算“实时协作”；所有基于 WebSocket 自建的私有协作插件在 2026 年已基本退出主流——不是不能用，是维护成本高、冲突多、调试难。
Live Share 必须统一配置的三项 setting
团队里只要有一人没配对，协作会卡在“等待加入”或“权限拒绝”界面，而不是报错提示。以下三项必须写进工作区 .vscode/settings.json，不能只存在用户级设置中：
-
"liveshare.featureSet"设为"stable"（而非"insiders"），避免预览版协议不一致导致连接中断 -
"liveshare.presence"设为true，否则对方看不到你当前光标位置和文件打开状态 -
"liveshare.shareServerProcess"设为false，禁用本地进程共享——它会意外暴露终端历史、未保存临时文件，且在 Windows + WSL 混合环境下极易崩溃
协作时代码格式化失效的根源与解法
当 A 在 VSCode 里按 Shift+Alt+F 格式化，B 却看到缩进错乱、引号不统一，这不是 Live Share 同步问题，而是格式化器未被双方识别为“同一套规则”。常见错误现象包括：
- B 的编辑器右下角显示
Prettier，但实际执行的是ESLint --fix - 保存时自动格式化触发，但只作用于 A 的视图，B 看到的仍是原始排版
- 团队
.prettierrc已提交，但 B 的 VSCode 读取的是自己用户目录下的同名文件
解决方法只有两个条件同时满足：
- 在工作区
.vscode/settings.json中显式指定："editor.defaultFormatter"为团队约定的扩展 ID（例如"esbenp.prettier-vscode"） - 禁用所有用户级格式化相关设置，尤其是
"editor.formatOnSave"和"editor.formatOnType"必须从用户 settings.json 中彻底删除，只保留在工作区配置里
Git 提交信息不同步与分支切换混乱
协作过程中，A 切到 feat/login 分支调试，B 还停留在 main，结果 A 推送一个未测试的 commit，B 本地 git status 显示“ahead of origin/main”，但 GitLens 面板里却看不到任何差异——这是 VSCode 的 Git Provider 缓存未刷新导致的。
根本原因在于 Live Share 默认不广播 Git 状态变更事件，每个客户端独立轮询。容易踩的坑：
- 误以为“共享编辑”等于“共享 Git 上下文”，实际分支、暂存区、stash 都是隔离的
- 在共享会话中执行
git checkout或git pull，仅当前客户端生效，对方无感知 - 使用 VSCode 内置终端执行 Git 命令，输出可能被 Live Share 拦截或延迟渲染
实操建议：
- 协作前约定主干分支，所有人手动切到同一分支再开始共享
- 禁用
"git.autofetch"（设为false），防止某人后台静默拉取造成状态偏差 - 用命令面板（
Ctrl+Shift+P）执行Git: Refresh Repository手动同步状态，比等自动轮询可靠
真正难的不是开启协作，而是让所有人默认忽略“我在远程编辑”的错觉——光标同步了，终端没同步；代码变了，Git 状态没变；格式化跑了，但对方的 Prettier 配置路径指向了错误的 node_modules。这些细节不靠文档，靠第一次协作失败后当场改配置、加注释、推 commit。团队规范不是写在 Wiki 里，是刻在 .vscode/settings.json 的每一行注释里。
