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”不等于用户收到了，尤其移动端网络不稳定。
