结论是别从零写WebSocket服务，用现成框架嵌入业务逻辑，重点放在协同状态同步和冲突解决上；因为gorilla/websocket仅提供底层连接能力，缺乏消息顺序保证、连接生命周期管理、操作合并（OT/CRDT）等协同编辑必需的机制，直接使用会导致状态不一致、光标错乱、并发冲突等问题。
直接说结论：别从零写WebSocket服务，用现成框架嵌入业务逻辑，重点放在协同状态同步和冲突解决上。
为什么不能直接用 gorilla/websocket 写协同编辑服务
很多人一上来就抄 gorilla/websocket 的 echo 示例，然后往里塞 JSON 消息广播——这在两人编辑一个文档时还能跑通，但到三人以上、操作频次高时就会暴露问题：
-
conn.WriteMessage()是阻塞调用，多个 goroutine 并发写同一连接会 panic（常见错误：write tcp: use of closed network connection） - 没有消息顺序保证，A 发“插入文字”、B 发“删除段落”，如果广播顺序错乱，客户端状态立刻不一致
- 缺乏连接生命周期管理，断线重连后无法自动恢复光标位置、选区、操作历史
- 没做操作合并（Operational Transformation 或 CRDT），两个用户同时改同一行，最终文本大概率错乱
选哪个 Go WebSocket 框架更合适
不是比“谁更快”，而是看“谁更容易接入协同逻辑”。三个主流选项的实际差异：
-
Webchat-DEV：纯标准库实现，二进制小、无依赖，但只提供连接/房间/广播基础能力，OT/CRDT 得自己实现，适合已有协同算法团队的小项目 -
Chatwire：内置连接池、心跳、消息队列抽象，支持自定义消息中间件钩子，HandleMessage函数可插拔，方便把 OT 变换逻辑塞进去 -
GoFrame：自带gfcli生成 WebSocket controller，支持自动绑定 struct 消息体、校验、日志追踪，对新手友好，但默认不带协同算法，需配合ot-go或crdt-go库使用
推荐路径：中小团队用 GoFrame + ot-go；高一致性要求（如代码协作）用 Chatwire + 自研 CRDT；极简部署场景用 Webchat-DEV + 服务端单点状态机。
立即学习“go语言免费学习笔记（深入）”；
协同编辑必须处理的三个底层细节
无论选哪个框架，这三个点漏掉一个，上线后就会出现“用户看到别人打字但自己光标乱跳”或“保存后内容消失”这类问题：
-
操作序列号（seq）必须全局单调递增：不能靠客户端时间戳，得用服务端
atomic.AddInt64(&seq, 1)或 Redis INCR。否则 OT 合并时无法判断操作先后 -
每个连接要绑定唯一 clientID 和 documentID：避免 A 编辑 doc1、B 编辑 doc2 却被广播到同一个 room。框架里通常叫
room.Join("doc-123")，别直接room.Broadcast() -
断线重连必须携带 lastSeq：客户端 reconnect 时 HTTP query 带
?last_seq=42，服务端只推送 seq > 42 的操作，而不是全量重发——否则重连瞬间刷屏导致卡死
一个最小可行的协同消息结构设计
别用裸字符串传操作，定义清晰的 message struct，框架才能做校验和路由：
type EditOp struct {
DocID string `json:"doc_id"`
ClientID string `json:"client_id"`
Seq int64 `json:"seq"`
Type string `json:"type"` // "insert", "delete", "retain"
From int `json:"from"`
To int `json:"to"`
Text string `json:"text,omitempty"`
Retain int `json:"retain,omitempty`
}
关键点：
-
Type必须限定为枚举值，避免客户端传"INSERT"或"insert "导致服务端解析失败 -
From/To用绝对偏移而非相对位置，服务端做 OT 时才可确定性计算 - 所有字段加
json:tag，GoFrame 或 Chatwire 的自动绑定才生效；gorilla/websocket手动json.Unmarshal容易漏字段
真正难的从来不是建立 WebSocket 连接，而是让十个用户同时敲键盘时，每个人屏幕上显示的内容严格一致——这取决于你如何设计操作流、如何做状态收敛、以及是否愿意为一次光标移动付出额外的网络 round-trip 开销。
