vs code 原生不支持协同编辑，因其单机架构和本地 monaco 内核未暴露跨设备同步接口，所有协同插件均需自建 diff/patch、网络信道与状态收敛逻辑，工程复杂度高且稳定性差。
VS Code 插件市场里没有现成的、开箱即用的“协同开发插件”——所谓实时多人编辑、共享光标、状态同步这类功能，vscode 本身不提供底层支持，官方也明确不计划加入。所有打着“协同开发”旗号的插件，本质都是绕过原生限制、靠 WebView + 自建信道 + 状态桥接来模拟，稳定性、权限、调试成本都远高于普通插件。
为什么 VS Code 原生不支持协同编辑
VS Code 是单机桌面应用，编辑器核心（Monaco）运行在本地渲染进程，所有文档模型、光标位置、折叠状态都驻留在内存中，不暴露跨进程/跨设备的实时同步接口。Extension API 中没有任何 onTextChangeBroadcast 或 registerCollaborativeSession 类型的函数。
这意味着：任何协同能力都必须自己实现三件事——文本差异计算（diff/patch）、网络信道（WebSocket / WebRTC）、客户端状态收敛（OT 或 CRDT）。这不是配置问题，是工程量级问题。
- 官方插件如
Live Share实际是微软私有服务，客户端重度依赖 Azure 后端，且仅对部分语言/调试器做适配，不开放协议 - 开源方案如
teletype（已归档）或codecollab都因无法跟上 VS Code 主线 API 演进而停止维护 - 所有“协同”类插件在
package.json的activationEvents里都只能写onStartupFinished或onCommand:，没法监听文档变更广播
想在插件里加协同功能？先确认你真需要它
多数所谓“协同需求”，其实只是共享配置、同步片段、统一代码风格——这些完全不需要实时编辑，用现有机制就能解决：
- 共享代码片段 → 用
vscode.workspace.getConfiguration()读取用户设置，配合vscode.workspace.onDidChangeConfiguration响应变更 - 统一 ESLint/Prettier 规则 → 直接在项目根目录放
.eslintrc.cjs和.prettierrc，插件只需调用vscode.commands.executeCommand('eslint.applyAutoFix') - 远程执行命令（如一键部署）→ 通过
vscode.window.withProgress调起child_process.exec或 fetch API，不涉及编辑器状态同步
如果你确实要实现两人同时改同一行代码、看到对方光标移动——那不是写个插件的事，是得搭一套带鉴权、心跳、冲突 resolution 的后端服务，并在 WebView 里重写 Monaco 编辑器逻辑。
能用的替代路径：聚焦可落地的协同增强点
与其硬啃协同编辑，不如从 VS Code 已开放的协作接口切入，做真正稳定、易交付的功能：
-
vscode.workspace.findFiles+vscode.workspace.textDocuments→ 批量扫描团队成员常用文件模板，生成可复用的snippetsJSON 并推送到 Git -
vscode.window.registerWebviewViewProvider→ 在侧边栏嵌入轻量看板（如 PR 状态、CI 进度），用 GitHub REST API 拉取数据，避免 WebSocket 维护成本 -
vscode.languages.registerCodeActionsProvider→ 对团队约定的注释格式（如// @reviewed-by: alice）提供快速插入/跳转，比实时光标更有实际价值
所有这些，都不依赖跨实例通信，不挑战 VS Code 安全沙箱，上线后不会因为一次 vscode 小版本更新就崩溃。
真正卡住协同插件落地的，从来不是前端交互，而是你怎么让两个独立运行的 VS Code 实例，在不越权、不降性能、不引入额外服务的前提下，达成状态一致。这个问题没标准解——连 Live Share 都要求双方装插件、登录微软账号、接受后台进程常驻。
