WebSocket vs SSE vs gRPC Stream：实时推送三选一的工程判断

Sat, 27 Jun 2026 00:00:00 +0000

引子：实时推送是个伪命题

WebSocket、SSE、gRPC Stream 都能做到"实时"，但这三个词在工程上的体感天差地别。你的老板可能觉得"不就是把数据推给用户吗，哪个有现成的就上哪个"，做过的人才知道选错了是多大的坑。

我见过太多团队选型的理由是这样的：“实时推送嘛，那肯定是 WebSocket”、“gRPC 最先进，用新的准没错”、“SSE 太弱了，不支持双向”。这些判断单独拎出来都不算错，但放在具体场景里，可能让你多花几倍的运维成本。更扎心的是——很多人刚上线的前两个月觉得选什么都一样，等业务量上来、用户变多、问题开始冒，才意识到当初的选择有多贵。

选错了不是不能用。WebSocket 做单向推送也能跑，gRPC 做浏览器推送也能搭 gRPC-Web 代理。但运维成本、调试体验、扩展潜力的差距会在业务增长时集中爆发——nginx 超时断开你没设置心跳、WebSocket 连接泄漏导致 goroutine 堆积、浏览器 SSE 连接数打满用户看到空白页面，每一个都是线上事故级别的翻车点。

今天不聊协议细节（这些协议的 RFC 和官方文档写得比我清楚），我只讲选型时应真实感受到的几个维度。看完你至少知道：为什么我建议你"默认选 SSE，不够了再上 WebSocket，微服务间用 gRPC Stream"。

第一块：三张牌各自的长相

WebSocket：全双工是你的超能力，也是你的包袱

WebSocket 的三板斧：客户端和服务端随时能发、二进制和文本都支持、帧开销极低（数据帧头部只有 2-6 字节）。这些特性让它成为聊天、协同编辑、游戏、金融行情等场景的不二之选。

但它最大的问题是——WebSocket 只负责传帧，不关心帧里面是什么。这既是力量也是负担。你需要自己定义消息格式（JSON？Protobuf？MessagePack？）、自己实现心跳（否则 nginx 默认 60s 断开）、自己写重连逻辑、自己管连接池和 hub 模式。而当你花了一周把这些基础设施搭好，回头看需求，发现其实只需要服务端定时推送一下——SSE 两小时就搞定了。

Go 生态里两个主流库的取舍：

gorilla/websocket——存量最大、文档最多，社区有大量现成示例和教程。但原仓库 2022 年底归档了，虽然有社区 fork 在维护，但总归不是官方推荐。最大的坑：不支持并发写——两个 goroutine 同时调用 WriteMessage 直接 panic。你需要用 hub goroutine 串行化所有写操作，这会增加不少样板代码。
coder/websocket（原 nhooyr/websocket）——新项目首选。API 带 context.Context，支持并发写，零外部依赖，还支持 WASM 编译和 permessage-deflate 压缩。Go 官方推荐了这个库。如果你现在开新项目，没有历史包袱，别纠结，直接用它。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// WebSocket 服务端 - coder/websocket
func wsHandler(w http.ResponseWriter, r *http.Request) {
 conn, err := websocket.Accept(w, r, nil)
 if err != nil { return }
 defer conn.Close(websocket.StatusNormalClosure, "bye")

 ctx, cancel := context.WithTimeout(r.Context(), time.Hour)
 defer cancel()

 go func() {
 for {
 _, msg, err := conn.Read(ctx)
 if err != nil { break }
 log.Printf("recv: %s", msg)
 }
 }()
 // 写循环 + 心跳
}

SSE：看起来最弱，但恰恰因为弱所以简单

SSE 可能是工程界被低估最严重的协议之一。

SSE on Zampo Blog

WebSocket vs SSE vs gRPC Stream：实时推送三选一的工程判断

引子：实时推送是个伪命题

第一块：三张牌各自的长相

WebSocket：全双工是你的超能力，也是你的包袱

SSE：看起来最弱，但恰恰因为弱所以简单