Gin本身不支持消息订阅，因其仅为HTTP路由框架，gin.Engine无内置pub/sub机制且不维护连接状态；实现即时通知需依赖WebSocket或SSE等长连接技术，订阅管理须独立构建并线程安全。
为什么 Gin 本身不支持消息订阅，得自己搭？
Gin 是 HTTP 路由框架，gin.Engine 没有内置的发布/订阅（pub/sub）机制，也不维护连接状态。你要做“即时通知”，本质是让服务端能主动推消息给已连接的客户端——这必须靠长连接（如 WebSocket）或 Server-Sent Events（SSE），而 Gin 只负责把请求转给 handler，剩下的得你来组织。
常见误区是试图用 gin.Context 缓存连接或广播消息，结果出现 panic：http: Handler closed due to error 或 goroutine 泄漏。根本原因是 HTTP handler 生命周期短，不能跨请求持有连接。
- 别在 handler 里直接用全局 map 存
*gin.Context或http.ResponseWriter—— 它们不是线程安全的，且响应写完就失效 - WebSocket 场景用
gorilla/websocket（比 Gin 内置的更成熟），SSE 场景用标准http.ResponseWriter保持流式写入 - 订阅关系管理必须独立于路由逻辑，推荐用
sync.Map存用户 ID → 连接句柄，配合context.WithCancel控制生命周期
用 gorilla/websocket 实现带订阅分组的连接管理
HTTP 升级为 WebSocket 后，每个连接就是一个持久 goroutine。关键不是“怎么连”，而是“怎么管”：谁订阅了哪个 topic？断连时如何清理？广播时如何过滤？
示例中，用 map[string]map[*websocket.Conn]bool 管理 topic → conn 映射，但注意：这个 map 必须用 sync.RWMutex 保护，否则并发写 panic。更稳妥的做法是用 sync.Map + 封装结构体：
立即学习“go语言免费学习笔记（深入）”；
type TopicManager struct {
topics sync.Map // string → *topic
}
<p>type topic struct {
conns sync.Map // *websocket.Conn → struct{}
mu sync.RWMutex
}
- 客户端订阅时，调用
topic.add(conn)，同时启动读协程监听 ping/pong 和关闭帧 - 服务端发消息走
TopicManager.Publish("order:123", data)，内部遍历该 topic 所有 conn，跳过已关闭的（用conn.WriteMessage前先conn.SetWriteDeadline） - 务必在 defer 里调用
conn.Close()和topic.remove(conn)，否则内存泄漏比想象中快
HTTP handler 怎么安全触发 WebSocket 广播？
比如订单创建后要通知所有订阅 order:123 的前端，你不能在 POST /orders handler 里直接调用 wsConn.WriteMessage——那是个不同 goroutine 里的连接句柄，而且可能已断开。
正确做法是解耦：HTTP handler 只往 channel 或消息队列（如 chan PublishEvent）发事件，由单独的广播 goroutine 消费并投递：
type PublishEvent struct {
Topic string
Data []byte
}
<p>var pubSub = make(chan PublishEvent, 1000)</p><p>// 在 HTTP handler 中：
go func() { pubSub <- PublishEvent{Topic: "order:" + orderID, Data: payload}}()</p><p>// 单独 goroutine：
for evt := range pubSub {
tm.Publish(evt.Topic, evt.Data)
}
- channel 缓冲区大小要设（如 1000），避免 HTTP handler 阻塞；满时考虑丢弃或告警，别用无缓冲 channel
- 别在 HTTP handler 里直接调用
tm.Publish，尤其当tm.Publish里有锁或网络 I/O，会拖慢接口响应 - 如果业务量大，建议换轻量消息中间件（如 Redis Pub/Sub），Gin handler 只做
redis.Client.Publish，由另一个服务监听并转发 WebSocket
为什么 SSE 比 WebSocket 更适合简单通知场景？
如果你只需要“服务端→客户端”的单向推送（比如系统公告、进度更新），SSE 比 WebSocket 更轻量：不用额外库、自动重连、天然兼容 HTTP/2 和反向代理（Nginx 默认透传 text/event-stream）。
Gin 中实现 SSE，核心是设置好 headers 并保持响应流打开：
c.Writer.Header().Set("Content-Type", "text/event-stream")
c.Writer.Header().Set("Cache-Control", "no-cache")
c.Writer.Header().Set("Connection", "keep-alive")
c.Writer.Flush() // 关键：确保 header 发出
<p>// 然后循环写入：fmt.Fprintf(c.Writer, "data: %s\n\n", msg)
- 每次写入后必须调用
c.Writer.Flush()，否则客户端收不到；Gin 默认不 flush，它等 handler 结束才刷 - 客户端断连时，
c.Request.Context().Done()会触发，用select { case 退出循环 - SSE 不支持二进制，所有数据走
data:字段，JSON 要手动json.Marshal后再套一层
真正难的不是连上，而是连接数上去之后的资源控制和 topic 隔离——每个 SSE 连接占一个 goroutine，没清理机制的话，1000 个连接就是 1000 个常驻 goroutine。
