SSE不适合协同编辑核心逻辑，因其仅支持服务器到客户端的单向推送，无法实现操作广播、冲突解决和状态一致性所需的双向通信与操作标识能力。
SSE 本身不支持客户端向服务器发送数据，所以不能直接用于多用户协同编辑的状态同步。它只能单向推送——服务器发、客户端收。而协同编辑需要所有客户端的操作（比如光标位置、文本增删、用户在线状态）实时反映到其他人界面上，这本质是双向同步问题。
为什么 SSE 不适合协同编辑核心逻辑
协同编辑依赖三个关键能力：操作广播、冲突解决、状态一致性。SSE 缺少前两项支撑：
- 无法让某个用户的编辑动作“主动通知”服务器和其他人（SSE 客户端不能发消息）
- 没有内置机制标识操作来源、时间戳或版本序号，难以做 OT（Operational Transformation）或 CRDT 冲突处理
- 服务端无法按编辑会话分组推送——SSE 是全局流或按 URL 路径区分，缺乏用户/文档粒度的精准路由
但 SSE 可以辅助协同场景的某些环节
它适合承担“只读型”状态广播任务，作为 WebSocket 或其他双向通道的轻量补充：
- 在线用户列表更新：服务端检测某用户加入/退出编辑会话后，通过 SSE 推送当前在线成员名单（纯展示用）
- 只读状态广播：如文档锁定提示（“张三正在编辑第3段”）、保存成功提示、系统公告等非交互性信息
- 低频元数据同步：文档最后修改时间、版本号、权限变更等不需要即时响应的数据
真正可行的协同编辑实现方式
必须用双向通信协议打底，再结合协同算法：
立即学习“Java免费学习笔记（深入）”；
- 首选 WebSocket：建立持久连接后，每个客户端可随时发送操作指令（如 {type:"insert", pos:12, text:"a", userId:"u123"}），服务端广播给同文档其他用户，并运行 OT 或 CRDT 算法保证最终一致
- 搭配 HTTP API 补充：首次加载文档内容、提交最终版本、处理离线缓存等仍可用普通请求
- 服务端需维护会话上下文：按文档 ID 或协作房间 ID 分组管理连接，避免全量广播；同时记录操作日志用于回滚与调试
如果坚持用 SSE 做“伪协同”，风险很高
有人尝试绕过限制，比如：
- 每次编辑都触发一次 POST 请求上报操作，再由服务端通过 SSE 广播给其他人——但这变成“轮询+推送”混合模式，延迟高、易丢操作、无顺序保证
- 前端本地模拟协同逻辑，仅靠 SSE 接收他人快照式状态（如整段 HTML）——无法处理并发编辑冲突，用户体验断裂
这类做法在小范围演示可能跑通，但用户一多、编辑一快，就会出现内容错乱、光标漂移、状态不同步等问题。
