sublime text 不支持原生多人实时协作编辑，因其无内置网络模块与文档状态同步机制；所谓“协作插件”仅实现文件同步或界面一致，不处理光标、选区、输入流及并发合并；实时共编需依赖外部服务（如 live share），sublime 无对应协议支持；自动同步工具（dropbox/rsync/git）易致冲突并损坏本地状态文件；remotesync、gitgutter 等被误传为结对工具，实则仅支持单向传输、差异显示或风格统一，与协同编辑无关；唯一可行路径是退守异步工作流：基于 git 分支协作、手动提交、sublimerge 可视化合并，并在真正需要实时结对时切换至 vs code 或 jetbrains 等原生支持工具。
Sublime Text 本身不支持原生多人实时协作编辑，任何“结对编程”方案都必须依赖第三方插件或外部服务，且存在明显延迟、冲突风险和权限盲区。
为什么不能直接用 Sublime 做实时协同？
Sublime Text 是单机本地编辑器，没有内置网络通信模块，也不维护文档状态同步机制。所谓“协作插件”（如 Sublimerge、SyncedSideBar）只解决文件同步或界面一致性，不是协同编辑——它们不会广播光标位置、选区或输入流，更不会处理并发修改合并。
- 所有“实时共编”功能实际由外部服务（如 VS Code 的 Live Share、CodeSandbox、GitHub Codespaces）提供，Sublime 没有对应协议支持
- 试图用 Dropbox / rsync / git 自动同步文件会导致频繁冲突：
.sublime-project和.sublime-workspace文件含本地路径与临时状态，跨机器写入必然损坏 - 即使强制监听文件变更并 reload，Sublime 不保证光标/折叠/书签等上下文同步，两人同时敲字大概率覆盖对方未保存的改动
哪些插件被误传为“结对编程工具”？
搜索结果里常出现的几个插件，实际能力与宣传严重不符：
-
RemoteSync：仅支持 FTP/SFTP 单向上传/下载，无双向 diff，不处理冲突，也不能共享编辑状态 -
GitGutter：只显示当前文件 Git 差异，不能拉取他人未 push 的修改，更不参与编辑过程 -
EditorConfig：统一缩进/换行风格，和协作编辑完全无关，连网络都不走 -
SublimeLinter或SublimeREPL：分别做语法检查和本地交互式运行，跟多人编辑零关系
如果非要 Sublime + 协作，唯一可行路径是什么？
放弃“实时共编”幻想，退回到轻量级协同工作流：一人主控，他人通过异步方式参与评审与反馈。关键在隔离编辑与同步动作：
- 用
git管理源码，所有人 clone 同一仓库，分支命名带人名（如pair/jane-refactor-login） - 禁用所有自动保存插件（如
AutoSave），每次手动Ctrl+S后立刻git add -u && git commit -m "wip" - 用
git diff --no-index对比本地文件与队友最新 commit，再用Sublimerge可视化合并，而非边写边同步 - 调试/运行阶段统一走容器或远程终端（如
ssh连到 dev server），避免本地环境差异干扰
真正需要结对编程时，Sublime 就该让位——VS Code 的 Live Share、JetBrains 的 Code With Me、甚至浏览器里的 CodeSandbox 才是设计用来干这事的。Sublime 的强项是快速启动、低资源占用、精准正则替换，不是状态同步。硬塞协作需求，最后卡在光标不同步、断点失效、console 输出错乱上，反而拖慢节奏。
