Socket.IO重连后触发disconnect事件的异常问题排查与解决

这是Socket.io v4.x版本的预期行为。原因在于：当客户端因网络波动临时断连时，服务器端的旧连接并不会立刻感知到断开——它要等到下一次pingInterval触发后，超过pingTimeout仍没收到客户端的pong响应，才会触发disconnect事件。而如果客户端在这个检测窗口内完成重连，会建立一个全新的Socket连接，此时服务器会先收到新连接的connect事件，几秒后旧连接的超时检测完成，又会触发旧连接的disconnect事件，这就导致了你遇到的玩家列表错误。

下面是几个直接解决问题的方案：

1. 重连时主动清理用户的旧连接 #

利用Socket.io的身份验证机制，让前端在连接（包括重连）时携带用户唯一标识（比如userID），后端在收到connect事件后，先找到该用户所有已存在的旧连接并主动断开，避免旧连接后续触发disconnect干扰逻辑。

后端代码示例：

io.on('connection', async (socket) => {
  const { userID } = socket.handshake.auth;
  if (!userID) return;

  // 加入用户专属房间（用于快速查找该用户的所有连接）
  socket.join(userID);

  // 获取该用户的所有旧连接（排除当前新连接）
  const oldSockets = await io.in(userID).fetchSockets();
  for (const oldSocket of oldSockets) {
    if (oldSocket.id !== socket.id) {
      // 主动断开旧连接，此时旧连接的disconnect事件会被触发，但我们可以在事件里做过滤
      oldSocket.disconnect(true);
    }
  }

  // 正常处理玩家列表添加逻辑
  addPlayerToList(userID);

  socket.on('disconnect', () => {
    // 断开时先检查该用户是否还有其他活跃连接
    io.in(userID).fetchSockets().then(sockets => {
      if (sockets.length === 0) {
        // 没有活跃连接了再移除玩家
        removePlayerFromList(userID);
      }
    });
  });
});

前端连接时携带auth信息：

import { io } from 'socket.io-client';

const socket = io('http://your-server-url', {
  auth: {
    userID: '当前用户的唯一ID'
  },
  reconnection: true, // 开启自动重连（默认就是true）
  reconnectionAttempts: 5,
  reconnectionDelay: 1000
});

2. 优化玩家列表的移除逻辑 #

不要在disconnect事件触发时直接删除玩家，而是先确认该用户是否还有其他有效连接：

• 给每个用户维护一个连接计数，connect时+1，disconnect时-1，计数为0时再移除玩家；
• 或者通过用户专属房间，每次disconnect时查询该房间内的活跃连接数，为0才移除。

这种方式即使旧连接的disconnect事件延迟触发，也不会错误移除玩家——因为新连接已经存在，房间内还有活跃连接。

3. 缩短Ping检测窗口（减少延迟触发的概率） #

调整Socket.io的pingInterval和pingTimeout参数，让服务器更快检测到旧连接的断开，缩小重连后收到旧disconnect事件的时间窗口。

后端启动时配置：

const io = require('socket.io')(server, {
  pingInterval: 3000, // 每3秒发送一次ping
  pingTimeout: 5000   // 5秒没收到pong就判定断开
});

前端同步配置：

const socket = io('http://your-server-url', {
  pingInterval: 3000,
  pingTimeout: 5000
});

注意：参数不要设置得太小，否则会增加服务器和客户端的网络开销，根据你的业务场景调整（比如游戏场景可以适当缩短，平衡实时性和开销）。

为什么你的自定义心跳没解决问题？ #

自定义心跳是在业务层做的检测，而Socket.io底层的TCP连接检测还是依赖内置的ping机制，所以旧连接的超时触发依然会延迟。上面的方案1是从根源上消除旧连接的干扰，方案2是从逻辑上容错，方案3是缩短延迟窗口，三者结合使用效果最好。

内容的提问来源于stack exchange，提问作者Samarth Gupta