sublime text 无法在局域网内实现真正协同结对编程，因其无内置网络通信能力、插件 api 不暴露按键事件、不支持操作拦截与广播、也无运行时服务端，所有“局域网协作”插件（如 remotecollab）仍依赖已停服的中心化后端，无法完成光标同步、输入流合并或实时冲突消解。
Sublime Text 无法在局域网内实现真正协同结对编程
直接说结论：Sublime Text 没有内置网络通信能力，插件 API 不暴露按键事件、不支持操作拦截与广播、也不提供运行时服务端，因此任何所谓“局域网协同”插件都做不到光标同步、输入流合并或实时冲突消解。所谓“局域网模式”只是把远程服务器地址换成 192.168.x.x，但后端服务（如已停服的 Floobits）不存在，插件就会卡在连接超时或静默失败。
RemoteCollab 插件安装后为什么连不上局域网节点
RemoteCollab 声称支持局域网协作，但实际依赖中心化服务端做 OT（Operational Transformation）协调。它没有内置 P2P 能力，也不监听本地端口供其他机器直连——所有通信仍走其官方域名（如 collab.sublimesync.com），而该域名自 2025 年底起已不可解析。即使你手动改 hosts 把域名指向局域网某台机器，RemoteCollab 也不会启动监听，因为它根本不实现服务端逻辑。
- 安装后右键无
Start Collaboration菜单项 → 实际是插件未初始化，控制台会报Connection refused或timeout - 尝试配置
"host": "192.168.1.100"到插件设置里 → 无效，插件不读取该字段，硬编码只连固定域名 - 用 Wireshark 抓包可见：只有 outbound DNS 查询和 HTTPS 连接尝试，无本地 TCP 监听行为
替代方案：用 Git + Sublime 插件做异步结对
如果团队必须用 Sublime，唯一可行路径是放弃“实时”，转向基于 Git 的明确分工与快速合并。关键不是让两人同时敲同一行，而是让修改可追溯、可评审、可回退。
-
GitSavvy：提供内建 Git 界面，支持一键git commit -am、git pull --rebase，避免 merge 提交污染历史 -
Sublimerge：可视化三路合并，高亮显示冲突块，支持鼠标点击接受/拒绝变更，比命令行git mergetool更直观 -
EditorConfig+ 统一.editorconfig：强制缩进、换行符、字符集一致，减少因格式差异引发的假冲突 - 禁用
SyncedSideBar或SynCText类插件：它们只是镜像文件列表或轮询覆盖本地副本，容易让人误以为“已同步”而跳过git pull
为什么 Dropbox/rsync 同步 Packages/ 目录会出问题
有人试图用局域网 NAS 或 Dropbox 同步整个 Packages/ 目录来“共享环境”，这会导致严重损坏：
-
.sublime-project和.sublime-workspace文件含绝对路径（如C:UsersAlice...），跨机器加载时侧边栏空白、书签失效、折叠状态错乱 - 插件缓存文件（如
Package Control.cache）被并发写入，下次启动可能报ImportError: No module named 'package_control' -
GoImports.sublime-settings中若硬写"command": "C:\go\bin\goimports.exe"，另一台机器路径不同就直接失效 - 正确做法是只同步
Packages/User/Package Control.sublime-settings和各插件的*.sublime-settings，且所有路径用${HOME}或留空交由系统环境解析
真正的协同编辑不在编辑器里，而在分支命名规范、提交信息约定、PR 评审流程里。Sublime 是个好工具，但它不是协作协议栈的一部分——这点容易被忽略，但恰恰是最关键的限制。
