Go实时消息推送需用并发安全的广播通道，WebSocket适合双向通信，SSE适合单向通知；HTTP Handler中直接WriteMessage会因非并发安全、阻塞写入和生命周期不匹配导致panic或卡死，应通过带缓冲channel解耦触发与发送。
Go 语言实现实时消息推送，核心不是“连上就发”，而是构建可被外部触发的、并发安全的广播通道——WebSocket 是主流选择，SSE 更适合单向通知场景，二者选型取决于业务是否需要客户端反向通信。
为什么不能在 http.HandleFunc 里直接调用 conn.WriteMessage()
常见错误是：用户登录后，HTTP 接口里遍历所有 *websocket.Conn 并强行写入，结果程序 panic 或卡死。原因有三：
-
*websocket.Conn不是并发安全的，多个 goroutine 同时调用WriteMessage()可能导致写冲突或连接异常关闭 - 某个客户端网络卡顿或已断开，
conn.WriteMessage()会阻塞当前 goroutine，拖垮整个广播流程 - HTTP handler 是短生命周期，而 WebSocket 连接是长生命周期，二者生命周期不匹配，状态难以同步
正确做法是引入中间层：所有推送请求统一发到一个带缓冲的 broadcast channel（如 make(chan []byte, 100)），再由独立的 hub.run() goroutine 拉取并分发——这样既解耦了触发源和发送逻辑，又规避了并发写风险。
gorilla/websocket 升级失败：Connection closed before receiving a handshake response
这几乎 100% 是跨域校验问题，不是协议错误。默认情况下，upgrader.CheckOrigin 拒绝所有非同源请求，浏览器前端用 new WebSocket("ws://localhost:8080/ws") 就会卡在握手阶段。
立即学习“go语言免费学习笔记（深入）”；
- 开发阶段可临时放开：
CheckOrigin: func(r *http.Request) bool { return true } - 上线前必须白名单校验：
return r.Header.Get("Origin") == "https://myapp.com" - 若前端走 Nginx 代理，需确认它透传了
Origin头（加配置proxy_set_header Origin $http_origin;）
另外注意：前端 URL 必须用 ws:// 或 wss://，不能写成 http://，否则浏览器根本不会发起 WebSocket 握手。
如何从 HTTP 接口触发 WebSocket 推送（比如 POST /api/push）
这是真实业务中最常遇到的场景：运营后台发公告、订单状态变更、客服人工推送等，都依赖“HTTP 入口 → WebSocket 广播”链路。
jQuery实现select省市区三级联动下拉框，通过选择省，市区的值随之变化，非常适用于企业网站或者商城网站，用户在注册的时候填写的信息。php中文网推荐下载！
关键不在怎么发，而在怎么确保消息可靠落地。示例接口逻辑如下：
func pushHandler(w http.ResponseWriter, r *http.Request) {
var req struct{ Msg string }
json.NewDecoder(r.Body).Decode(&req)
// 只往 broadcast channel 发原始字节，不碰 conn
broadcast <- []byte(req.Msg)
w.WriteHeader(http.StatusOK)
}配套要求：
-
broadcastchannel 必须是全局变量，且已被hub.run()启动监听 - 每个
*Client需自带send chan []byte，且writePumpgoroutine 要用select+default防写死（见下条） - 若需定向推送（如只推给 user_id=123），则 HTTP 接口查
map[string]*Client，往对应 client 的sendchannel 发，而非全局broadcast
writePump goroutine 卡住？加 select + default 防阻塞
当某个客户端网络中断但 TCP 连接未及时关闭（如 NAT 超时、WiFi 切换），其 send channel 可能持续无消费，导致 writePump 在 client.send 处永久阻塞——进而让整个 hub.broadcast 流程停摆。
解决方法是在写入前加非阻塞判断：
func (c *Client) writePump() {
for {
select {
case message, ok := <-c.send:
if !ok {
c.conn.Close()
return
}
// 非阻塞写入，失败则清理连接
if err := c.conn.WriteMessage(websocket.TextMessage, message); err != nil {
c.conn.Close()
return
}
default:
// 防止 send channel 堵塞时卡死
time.Sleep(time.Millisecond * 10)
}
}
}更稳妥的做法是：用 select 包裹写操作，并设超时或加 default 分支，确保 goroutine 不因单个 client 异常而停滞——这才是生产环境能扛住千级并发的关键细节。
