WebSocket推送必须解耦连接管理与消息触发，需用全局广播channel和独立goroutine分发，避免阻塞；连接池、标签路由、ACK机制及离线补偿等保障到达率。
WebSocket 推送必须解耦连接管理与消息触发
很多人卡在“连上了却推不出消息”，根本原因是把 conn.WriteMessage() 写死在 WebSocket handler 里——那只是回显，不是服务端主动推送。真正的新闻推送系统，得让 HTTP 接口、定时任务、数据库变更监听等外部事件，能随时把消息塞进广播通道。
- 必须用一个全局带缓冲的
broadcastchannel（如make(chan []byte, 100)），避免单个客户端写失败导致整个广播阻塞 - 单独起一个 goroutine 持续从
broadcast读取消息，再遍历clients map[uint64]*websocket.Conn分发——*websocket.Conn非并发安全，绝不能在 HTTP handler 里直接遍历写 -
upgrader.CheckOrigin开发时可临时设为return true，但上线前务必校验 Origin 头，否则 Nginx 反向代理后可能因头丢失而握手失败
短轮询适合小规模新闻站，但缓存和清空逻辑不能省
如果你的新闻后台只有几十个编辑或百来个内部审核员看“新稿件待审”，用短轮询比搞 WebSocket 更快上线、更稳、兼容 IE11。但它不是“查完就返回”，而是“查完要标记已读+防重复”。
-
messages绝不能存在内存map[string][]string里——进程重启全丢；必须用 Redis 或带 TTL 的本地缓存（如freecache.Cache） - 每次请求返回后，必须调用
redis.DEL("user:123:notifications")或cache.Delete("user:123:notifications")，否则下一次拉取还是旧消息 - 别用
json.NewEncoder(w).Encode()直接吐 JSON；短轮询响应是普通 HTTP，格式自由，但要加Cache-Control: no-cache头防浏览器缓存
消息落库必须异步 + 带状态回执，否则“发了=收到”是假象
新闻类推送对到达率敏感：一条突发快讯没触达，就是漏报。Go 系统里“写完 DB 就 return”不等于用户收到了，尤其移动端网络不稳定。
- 消息进入系统后，先异步写入 WAL 日志或 BadgerDB（非阻塞），再推送到 WebSocket 连接池；同步写 MySQL 会拖慢吞吐
- 客户端收到后必须主动上报
ack?msg_id=abc123，服务端用sync.Map存未确认 ID，30 秒超时未 ack 则重试（最多 2 次，指数退避） - 重试失败的消息，转存到 Kafka topic
news-offline，由离线补偿服务兜底推送 App Push 或短信
标签路由不能硬编码，动态订阅关系要用读写锁保护
新闻系统要支持“只推科技板块”“屏蔽娱乐频道”，就得让用户能随时订阅/退订标签。但直接在 map 上增删订阅关系，容易因并发导致数据错乱或死锁。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.RWMutex包裹subscriptions map[string][]*Client，增删时用Lock()，分发时用RUnlock()——千万别在锁里做 DB 查询或 HTTP 调用 - 写入消息时按标签哈希到 shard（如
shardID := int(hash(tag)) % 64），每个 shard 有独立chan *Message和消费 goroutine，避免所有消息挤在一个 channel 里排队 - 退订操作不要立刻从 map 删除，先标记
status: "pending_unsub"，等当前 shard 消费完该用户最后一批消息再清理，防止漏推
真正难的从来不是“怎么把消息发出去”，而是“怎么确保它只发给该发的人、发完有人认账、发断了还能捡回来”。这些点不埋进代码里，上线后半夜报警的永远是推送服务。
