Teletype 已彻底不可用，因服务端停摆且 Atom 1.60+ 移除支持；AtomPair 是唯一可用替代方案，依赖 Pusher 实现点对点同步，但不共享光标、折叠等状态。
Teletype 已彻底不可用，不是配置问题，是服务端停摆 + 客户端弃用双重失效。别再花时间调试连接、重装插件或降级 Atom 版本——wss://teletype.atom.io 自 2025 年底起返回 503 Service Unavailable，且 Atom 1.60+ 已移除对其运行支持。
为什么 Teletype 命令面板里搜得到却点不动？
Atom 的命令面板（Cmd+Shift+P）能列出 Teletype: Share Workspace，只是因为插件文件残留；实际执行时会尝试初始化 WebSocket 连接，但目标地址已不可达。终端运行 curl -I https://teletype.atom.io 可直接验证：大概率返回 HTTP/2 503 或超时。
更关键的是，Atom 1.60+ 基于新版 Electron，其 WebSocket 实现与 teletype-crdt 依赖的旧版 ws 库不兼容，模块加载静默失败。你看到的「Installed」状态，仅表示文件存在，不代表能运行。
-
siteId在多标签/多窗口下极易重复或错乱，导致字符插入位置漂移 - 对缩进调整、JSON 字段重排、注释块折叠等结构感知操作无处理逻辑，同步后文本不可逆乱序
- 无 pending 变更队列反馈机制，网络抖动时
pendingChanges积压，光标卡在错误位置
AtomPair 是目前唯一还能跑的实时结对插件
它不依赖中心化服务，基于 Pusher 的 WebSocket 实现点对点同步，且明确支持 Atom 1.60+。安装后仍需注意几个硬限制：
- 必须手动注册 Pusher 账号并填入
pusherAppKey和pusherCluster，否则会静默失败 - 只同步编辑内容，不共享光标位置、折叠状态、选区高亮 —— 这些靠客户端自行渲染，不同步
- 多标签页同步有效，但每个标签页独立建立连接，网络不稳定时可能个别标签失联
-
atom-pair不处理语言服务（如自动补全、跳转定义），这些仍由本地插件提供，协作方看到的是纯文本流
启动命令为 AtomPair: Start Session，生成会话 ID 后，对方需手动执行 AtomPair: Join Session 并粘贴 ID —— 没有 Slack/HipChat 一键邀请，也无二维码分享。
团队代码规范必须靠项目级配置落地
想靠导出 ~/.atom/config.cson 统一风格？行不通。这个文件存的是本地偏好（主题、字体大小），不是代码规则。强行复制会导致插件路径错乱、跨平台路径解析失败、语言格式规则缺失。
真正有效的组合是：
-
.editorconfig放项目根目录，声明式定义缩进、换行、空格等基础规则（必须写root = true） -
.prettierrc控制语义级格式（如引号、分号、括号位置），但要禁用prettier-atom的useEditorConfig选项，避免冲突 - 用
husky+lint-staged在pre-commit钩子中强制格式化，CI 流水线再校验一次
例如：若 .editorconfig 设 indent_size = 2，而 .prettierrc 写 "tabWidth": 4，保存时 Prettier 会优先执行后者，造成来回切换。
替代方案选型要看协作强度
如果只是看代码、做 Review，git status --short + gh repo sync 就够用，零延迟、零冲突；如果需要实时观察输入和命令执行，tmux 共享终端（atom --dev）比伪造 CRDT 更稳；如果真要手把手教人写某段逻辑，Parsec 或 Chrome Remote Desktop 的屏幕级控制延迟低于 50ms，反而更符合人眼感知节奏。
复杂点不在「怎么连」，而在「连上之后怎么不出错」——Teletype 的 CRDT 实现从设计上就不适配现代编辑器的多标签、结构感知编辑行为。现在所有能跑的替代方案，都绕开了同步算法本身，转而用更底层的通道（WebSocket、终端、显卡帧）传递原始事件或画面。
