因为redis.PubSub的Receive方法是阻塞调用，若在Gin HTTP handler中直接调用，会锁死当前goroutine，导致请求挂起、后续请求排队；必须将其移至独立goroutine中运行，并通过channel中转消息，确保handler快速返回。
为什么 Gin 里直接用 redis.PubSub 会卡住请求？
因为 redis.PubSub 的 Receive 方法是阻塞调用，一旦放进 HTTP handler，整个 goroutine 就停在那儿等消息，Gin 的请求线程被锁死，后续请求全排队——这不是“订阅”，这是“挂起”。
- 必须把
Subscribe和Receive放到独立 goroutine 中，让 handler 快速返回 - 别在 handler 里调
sub.Receive()，它不返回，除非连接断或超时 - 用
context.WithTimeout包裹Receive只能防卡死，不能解决并发模型错配问题
怎么安全地把 Redis 订阅逻辑和 Gin 路由解耦？
推荐启动时建立全局 *redis.PubSub 实例，用 channel 中转消息，避免每个请求都建连接、重复订阅。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在
main()初始化时调redisClient.Subscribe("notify")，保存返回的*redis.PubSub - 启一个 goroutine 调
sub.Receive()，把收到的redis.Message发到全局chan *redis.Message - Gin handler 只负责往 Redis 发布（
redisClient.Publish("notify", payload)），不碰订阅逻辑 - 需要实时推送的前端，改用 WebSocket 或 SSE，别指望 HTTP 短连接扛住 Pub/Sub 消息流
redis.Message.Payload 解析失败常见在哪？
Redis 发布的是 raw bytes，GoRedis 默认不自动 JSON 解码，Payload 是 []byte，直接当 string 用会乱码，强转结构体更会 panic。
- 检查是否误用了
msg.Payload当作字符串：先确认长度，再string(msg.Payload)看是否可读 - 如果发的是 JSON，必须手动
json.Unmarshal(msg.Payload, &v)，别漏掉 error 判断 - 注意 GoRedis v9+ 的
redis.Message字段名是Payload（不是Data或Body），拼错就取不到内容 - 发布端若用
redisClient.Publish(ctx, "topic", map[string]interface{}{...})，实际存的是 map 的默认 string 表示，不是 JSON 字符串——得显式json.Marshal
多个服务实例下，通知只被一个实例消费怎么办？
Redis Pub/Sub 是广播模型，所有订阅者都会收到消息。但如果你看到“只有单个 Gin 实例处理通知”，大概率是多个进程用了同一个 clientID 或复用了同一连接。
- 每个 Gin 实例必须用独立的
redis.Client和redis.PubSub，别跨实例共享 client 实例 - 不要在多个 goroutine 里共用一个
sub实例，Receive()不是并发安全的 - 如果用 Redis Cluster，Pub/Sub 只在 master 节点生效，从节点不转发订阅——确保所有实例连的是同一个 master 或启用了
redis.ClusterClient的 pubsub 支持 - 上线前用
redis-cli --scan --pattern "notify"确认频道确实有消息流入，排除发布端静默失败
Receive 因网络断开 panic，整个后台监听就停了；还有就是忘记关 PubSub.Close()，进程退出时连接泄漏。 
