前端无法直连 redis pub/sub，因其协议不兼容 websocket 标准；前端只需连接自身 websocket 服务并收发 json 消息，后端负责 redis 订阅、发布与状态同步。
前端无法直接连接 Redis Pub/Sub，这是个常见误解。Redis 的 Pub/Sub 机制运行在服务端，前端 WebSocket 客户端只能与你的应用服务器通信，所有 Redis 操作必须由后端完成。
为什么前端不能直连 Redis Pub/Sub
Redis 默认不开放公网访问，且其协议不是基于 HTTP/HTTPS 的浏览器可兼容协议；浏览器的 WebSocket API 只能连接符合 WebSocket 协议（RFC 6455）的服务端，而 Redis 的 Pub/Sub 是 TCP 层面的原生命令交互，不支持握手升级、帧格式、跨域等 Web 标准。
- 尝试用
new WebSocket("redis://...")会直接报错或连接失败 - 即使通过 WebSocket 代理桥接 Redis，也需额外服务层（如 Node.js 中间件），本质仍是“前端 → 自己的 WS 服务 → Redis”
- 浏览器中无法执行
PUBLISH或SUBSCRIBE命令——这些是 Redis CLI 或服务端 SDK 的能力
前端该做什么：只管连接、收发、状态管理
前端唯一要做的，是建立并维护一条到你自己的 WebSocket 服务（如 /ws）的稳定连接，并按约定的消息格式发送和解析数据。其余逻辑全部交给后端处理。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 连接时携带认证信息，例如把
token放在 URL 查询参数：ws://your-api.com/ws?token=abc123 - 发送消息用标准 JSON 格式，包含
type、to（群聊/用户ID）、content字段，避免裸字符串 - 监听
message事件，对event字段做分支处理（如"join"、"msg"、"offline"） - 主动实现心跳（如每 30 秒发一次
{"ping": true}），防止 Nginx 或云厂商 LB 断连
后端必须承担的三件事
真正串联 WebSocket 和 Redis Pub/Sub 的工作，全在服务端。以 Go + Gin + gorilla/websocket 为例：
-
连接注册：用户上线时，用
redisClient.SAdd("online_users", userID)记录在线状态 -
消息分发：收到某用户消息后，不直接广播给所有连接，而是调用
redisClient.Publish("chat:general", payload) -
订阅转发：每个 WebSocket 连接对应的 goroutine 需
redisClient.Subscribe("chat:general")，再将收到的 Pub/Sub 消息通过conn.WriteMessage()推给对应客户端
容易被忽略的关键点
很多人卡在消息“发出去了但别人收不到”，问题往往不在前端代码，而在后端的订阅生命周期管理——Redis 的 SUBSCRIBE 是长连接，必须和 WebSocket 连接共存亡。
- 如果用一个全局
redis.PubSub实例供所有连接共享，断连时未Unsubscribe，会导致内存泄漏和重复投递 - 不要在
handleWebSocket函数里直接Subscribe后就 return；必须起一个独立 goroutine 持续Receive()并写回 WebSocket - 前端看到“已发送”不等于“已送达”，需要后端在成功
Publish后返回{"ack": "msg_id"}，前端据此更新 UI 状态
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
