如何阻止socket.io-client触发onbeforeunload时提前断开连接

这个问题我之前也碰到过，核心原因是新版Socket.io默认开启了closeOnBeforeunload配置，会在beforeunload事件触发时自动断开连接，而不是等用户确认离开后再执行。而你之前用的2.1.3版本还没有这个默认行为，所以能正常工作。

下面是具体的解决步骤：

1. 禁用Socket.io的自动卸载断开 #

在初始化Socket.io客户端时，显式关闭closeOnBeforeunload选项，阻止它在beforeunload阶段自动断开：

const socket = io('你的服务器地址', {
  closeOnBeforeunload: false
});

2. 手动控制断开时机 #

利用浏览器的unload事件（这个事件只会在用户确认离开页面后才会触发），在这里手动断开Socket连接：

// 处理离开确认弹窗
window.addEventListener('beforeunload', (event) => {
  // 触发浏览器的确认弹窗（兼容不同浏览器写法）
  event.preventDefault();
  event.returnValue = '';
});

// 用户确认离开后，手动断开socket
window.addEventListener('unload', () => {
  if (socket?.connected) {
    socket.disconnect();
    // 或者使用 socket.close()，两者在新版Socket.io中效果一致
  }
});

为什么旧版本正常？ #

Socket.io在2.x后期版本才引入了closeOnBeforeunload这个配置项，默认值为true，目的是优化连接资源的释放。但这就导致了和beforeunload确认逻辑冲突的问题——在用户还没确认是否离开时，连接就已经断开了。而2.1.3版本没有这个自动断开的逻辑，只有当页面真正卸载（用户确认后）才会触发连接断开，所以符合你的预期。

额外注意事项 #

• 部分浏览器对unload事件中的异步操作限制严格，socket.disconnect()是同步触发断开的，所以不用担心被浏览器拦截。
• 测试时尽量在真实服务器环境下验证，本地开发环境可能因为浏览器缓存或调试模式有不同表现。
• 如果需要确保服务器端能正确收到断开事件，可以使用socket.disconnect(true)强制断开（不过一般默认的disconnect()就足够了）。

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