用 go-socket.io 支撑万级社交实时功能不可靠，需改用 gorilla/websocket + 自研 hub；因其广播遍历无分片、断线回调不及时、redis 适配器不管理连接生命周期，而自研方案通过 sync.map 分房、双 goroutine 读写、redis set+pub/sub 维护状态可保障可靠性。
直接上结论：用 go-socket.io 搭建社交类实时功能（如在线状态、群聊、消息已读）是可行的，但高并发下容易卡在单机广播和连接管理上；真要支撑万级活跃用户，得切到原生 gorilla/websocket + 自研 hub 路由层，否则一压测就暴露心跳延迟、房间同步不一致、断线重连丢事件等问题。
为什么 go-socket.io 在社交场景里容易崩
它模拟了 Node.js Socket.IO 的完整语义（命名空间、房间、自动重连、ack 回调），但 Go runtime 对这类“带状态的事件分发”没有天然优化。问题集中在三处：
-
server.BroadcastToRoom默认走内存 map 遍历，没做读写分离或分片，1000 个房间 × 50 人/房 → 每次广播触发 5 万次连接查表 - 客户端断线后，
OnDisconnect回调不一定及时触发，尤其在 NAT 网关超时场景下，s.Conn().RemoteAddr()可能已失效，导致“假在线”状态残留 - Redis 适配器只负责跨进程广播，不接管连接生命周期 —— 你得自己用 Redis Pub/Sub + TTL 维护用户在线状态，否则多实例部署时“谁在哪个房间”根本对不上
gorilla/websocket + 自研 hub 的最小可靠结构
社交应用最核心的是“谁在哪儿、消息发给谁、状态怎么同步”，不用框架反而更可控。关键模块就三个：
-
Hub：全局单例，用sync.Map存roomID → *sync.Map{clientID → *Client}，写操作加mu.RLock()，广播时用range迭代避免锁竞争 -
Client：每个连接一个 goroutine 负责conn.ReadMessage，另一个 goroutine 用conn.WriteMessage发消息，中间用chan []byte做缓冲，防写阻塞读 -
Presence：用 Redis 的SET user:123 room:feed EX 30 NX维护在线状态，搭配Pub/Sub同步“上线/下线”事件到所有 hub 实例
示例片段（简化版 hub.Broadcast）：
func (h *Hub) Broadcast(room string, msg []byte) {
if clients, ok := h.rooms.Load(room); ok {
clients.(*sync.Map).Range(func(_, v interface{}) bool {
if client := v.(*Client); client.Conn != nil {
select {
case client.send <h3>在线状态与已读回执的落地难点</h3><p>这两个功能看着简单，实际最容易出错：</p>
- “在线”不是连接存在就行 —— 得结合 WebSocket ping/pong 周期（建议设为 25s）+ 客户端定时上报心跳（如每 30s POST
/v1/presence/heartbeat），双保险防 NAT 断连检测失败 - “已读回执”必须服务端生成唯一
receipt_id，且存储要带 TTL（比如 7 天），不能只存内存；否则用户换设备登录，新客户端收不到旧消息的已读状态，体验直接断裂 - 别用
time.Now().Unix()当消息时间戳 —— 客户端系统时间可能不准，统一用服务端 NTP 校准后的时间，或者用逻辑时钟（如 Lamport timestamp）做排序
真正难的从来不是“怎么发消息”，而是“怎么确认对方收到了、什么时候收到的、现在还在不在”。这些细节不抠清楚，上线后用户投诉“消息显示已读但对方根本没看到”，排查起来比重构还费劲。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
