后端通过WebSocket向前端特定客户端推送消息的方案咨询

首先直接回应核心疑问：你提到的「存储WebSocket连接对象供发消息时调用」的思路方向是正确的，但不推荐用数组存储，基于唯一身份标识的键值映射结构才是生产环境的标准选择，几百个连接的场景下这套方案性能冗余非常充足，完全不需要额外的复杂组件。

具体实现步骤 #

• 第一步：握手阶段完成身份绑定
  客户端发起WebSocket连接时，必须在握手请求中携带当前登录用户的身份凭证（一般是已登录态的token、或者会话绑定的用户ID），服务端在握手拦截逻辑中校验凭证合法性，校验通过后才允许建立连接。

  注意：不要等连接建立完再发消息做身份绑定，握手阶段直接鉴权可以过滤掉无效的恶意连接，减少资源浪费。

• 第二步：用键值结构存储活跃连接
  连接正式建立后，以用户唯一ID作为键，对应的WebSocket连接实例作为值，存入全局可访问的并发安全Map结构中。如果业务允许同一个用户多标签页、多端同时在线，值要存为对应连接的Set集合，避免漏推消息。
  绝对不要用数组存储连接：数组没有身份索引，每次推送都需要遍历全量连接匹配目标用户，连接数上涨后性能会快速下降，还容易出现身份匹配错误导致消息推错人的问题。
• 第三步：定向推送逻辑
  当需要给特定用户推送消息（比如未支付提醒）时，直接拿目标用户ID从连接Map中取出对应的连接实例，校验连接处于活跃状态后，调用连接的send()方法下发消息即可，单次查询的时间复杂度为O(1)，性能极高。
• 第四步：连接生命周期维护
  必须监听每个连接的close、error事件，当连接正常断开、出现异常、或者登录态失效时，立刻把对应连接实例从Map中移除，避免内存泄漏，同时防止向已失效的连接写入数据抛出异常。
  额外要加心跳检测机制：TCP连接存在假死问题（比如用户直接断网、关设备没有走正常断开流程），服务端需要定时向所有连接发送ping帧，连续多次未收到pong响应的连接要主动断开并清理，避免无效连接长期占用内存。

极简实现参考（Node.js环境伪代码） #

// 全局连接存储：key为用户ID，value为对应用户的所有活跃WebSocket连接集合
const connectionStore = new Map();

wss.on('connection', (ws, req) => {
  // 握手阶段从请求头/请求参数解析校验登录态，获取当前连接对应的用户ID
  const currentUserId = parseAndVerifyAuth(req);
  if (!currentUserId) {
    ws.close(401, '身份校验失败');
    return;
  }

  // 将当前连接存入存储结构
  if (!connectionStore.has(currentUserId)) {
    connectionStore.set(currentUserId, new Set());
  }
  connectionStore.get(currentUserId).add(ws);

  // 连接关闭时清理存储
  ws.on('close', () => {
    const userConns = connectionStore.get(currentUserId);
    userConns.delete(ws);
    if (userConns.size === 0) connectionStore.delete(currentUserId);
  });
});

/**
 * 定向给指定用户推送消息
 * @param {number|string} userId 目标用户ID
 * @param {object} message 要推送的消息内容
 */
function pushToUser(userId, message) {
  const targetConns = connectionStore.get(userId);
  if (!targetConns?.size) return;
  const payload = JSON.stringify(message);
  targetConns.forEach(conn => {
    // 仅给处于打开状态的连接发消息
    if (conn.readyState === WebSocket.OPEN) conn.send(payload);
  });
}

规模扩展说明 #

如果后续业务增长到单台服务器承载不了上万级别的长连接，只需要在现有逻辑基础上增加一层消息路由即可：

• 每台WebSocket服务器仅维护本机上的连接映射
• 引入支持发布订阅的消息组件做跨节点路由，推送消息时按用户ID哈希找到连接所在的服务器节点，由对应节点完成最终下发即可，不需要重构核心逻辑。

内容的提问来源于stack exchange，提问作者Luca Prodan