JS socket.io客户端无法捕获服务端emit的action2事件排查

核心根因 #

故障是服务端长耗时计算阻塞连接心跳，导致客户端提前断连重连，和你怀疑的耗时长直接相关：

• Socket.IO 默认靠20秒超时的ping/pong心跳维持连接，服务端处理action1时同步执行50秒计算，期间完全无法响应客户端的心跳包，客户端等不到pong响应就会判定连接失效、自动发起重连。
• 服务端日志显示的emitting event "action2" to all [/]只是说明服务端往当前维护的连接列表发了消息，但此时触发请求的原连接已经失效，新建立的重连客户端收不到旧连接上投递的消息，所以Promise一直处于挂起状态，progress2不会打印。
• 短耗时任务因为执行时间小于20秒默认心跳超时，不会触发断连，所以能正常运行，和你观察到的现象完全吻合。

另外你的代码还有两个隐性bug会放大问题：

• 服务端调用sio.emit('action2')是全量广播，没有定向发给触发action1的客户端，多用户场景下会发错消息。
• 客户端先执行emit再注册事件监听，且用on注册监听没有做销毁，循环调用会堆积大量重复监听器，极端场景下会出现监听器还没注册完消息就到了的时序问题。

修复方案 #

1. 服务端（Python）修改 #

核心原则是不要在事件处理函数中阻塞执行长耗时任务，将计算逻辑放到后台任务执行，保证事件循环/工作线程能正常响应心跳：

@sio.on('action1')
def handle_analysis(sid):  # sid是触发当前请求的客户端唯一标识
    def run_long_calc():
        # 这里放原来的50秒计算逻辑
        # calc_result = .....
        # 定向给触发请求的客户端发消息，不要全量广播
        sio.emit('action2', data=calc_result, to=sid)
    # 把计算任务丢到后台线程执行，事件处理函数立刻返回，不阻塞心跳
    sio.start_background_task(run_long_calc)

如果不想改异步执行逻辑，也可以手动调大心跳超时阈值（不推荐，会导致所有请求都被长任务阻塞）：

# 初始化时把心跳超时调到大于最长计算耗时
sio = socketio.Server(ping_timeout=70000, ping_interval=30000)

2. 客户端（JS/TS）修改 #

• 对齐服务端心跳配置
• 调整时序：先注册一次性事件监听，再发请求
• 增加超时兜底，避免无限挂起

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

// 对齐心跳配置
export const socket = io("http://localhost:5550", {
  timeout: 200000,
  pingTimeout: 70000,
  pingInterval: 30000
});

async runCalculations() {
  console.log('progress1');
  let stdoutChunks: string = '';

  const getCalculations = () => {
    return new Promise((resolve, reject) => {
      // 先注册一次性监听，用once避免重复监听器堆积
      socket.once('action2', (msg) => {
        stdoutChunks += msg;
        resolve(stdoutChunks);
      });
      // 监听注册完成后再发请求
      socket.emit('action1');
      // 加2分钟超时兜底，避免无限挂起
      setTimeout(() => reject(new Error('计算请求超时')), 120000);
    });
  };
  await getCalculations()
  console.log('progress2');
  return {};
}

验证方式 #

修改后可以在客户端加连接状态日志，执行长计算期间如果没有触发disconnect、reconnect事件，就说明心跳正常，action2事件可以被正常捕获。

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