React StrictMode为何重复创建WebSocket订阅？清理正常仍存在该问题

问题场景与修复示例 #

你当前的自定义Hook在React 18 StrictMode开发模式下会触发两次WebSocket连接，原因是StrictMode会在开发环境中执行挂载→卸载→重新挂载的流程，以此检测资源泄漏问题。以下是修复后的Hook代码，可避免开发模式下的重复连接：

import { useEffect, useRef } from 'react';

function useSocket(url) {
  const socketRef = useRef(null);
  const isFirstMount = useRef(true);

  useEffect(() => {
    // 跳过StrictMode下的第一次挂载（会被立即清理）
    if (isFirstMount.current) {
      isFirstMount.current = false;
      return;
    }

    // 仅在有效挂载时创建连接
    socketRef.current = new WebSocket(url);
    socketRef.current.onopen = () => {
      console.log("Connected");
    };

    // 可添加消息处理、错误监听等逻辑
    socketRef.current.onmessage = (event) => {
      // 处理收到的消息
    };

    socketRef.current.onerror = (error) => {
      console.error("Socket error:", error);
    };

    // 组件真正卸载时清理连接
    return () => {
      if (socketRef.current) {
        socketRef.current.close();
        console.log("Closed");
        socketRef.current = null;
      }
    };
  }, [url]);

  // 返回socket实例供组件调用
  return socketRef.current;
}

你的问题解答 #

1. React的双重调用是否保证在第二次挂载前始终执行清理？ #

是的。在React 18 StrictMode的开发模式下，组件挂载流程严格遵循：第一次effect执行 → 立即调用其清理函数 → 第二次effect执行。这个顺序是明确保证的，目的是模拟组件在未来版本中可能出现的"卸载后重新挂载"场景，提前暴露资源未正确清理的问题。

2. WebSocket等外部资源是否应在React effects之外初始化？ #

不建议。组件顶层（effects之外）的代码会在组件每次渲染时执行，无法和组件的生命周期绑定，容易导致资源在组件未挂载时就被创建，或在组件卸载后仍未释放，造成泄漏。正确做法是在useEffect中初始化资源，并在其返回的清理函数中释放，确保资源生命周期与组件保持一致。可以通过useRef跨渲染保存资源实例，避免重复创建。

3. 生产级应用如何在保持StrictMode启用的情况下防止重复副作用？ #

生产级应用可采用以下几种方案：

• 用ref跟踪资源实例：通过useRef存储WebSocket、SDK实例等，在effect中判断实例是否已存在，仅在不存在时初始化，避免重复创建。
• 让副作用具备幂等性：后端层面处理重复连接，自动清理无效的旧连接；客户端层面，新连接建立后主动关闭旧连接，确保最终仅保留一个有效连接。
• 开发模式下跳过重复执行：通过ref标记是否为StrictMode下的第一次挂载，跳过该次的资源初始化（因为会立即被清理），仅在第二次挂载时创建资源。该逻辑仅影响开发环境，生产环境无双重调用，不影响正常业务。
• 全局单例管理：若多个组件共享同一个长连接，可将连接实例封装为全局单例，结合Context或状态管理库统一分发，确保整个应用仅存在一个连接实例。

4. React是否有官方推荐的长连接模式？ #

React官方没有针对长连接（WebSocket、SSE等）提供专属API，但给出了明确的实践原则：

• 资源初始化与清理必须绑定到组件生命周期，即放在useEffect中执行，清理逻辑放在effect的返回函数中。
• 使用useRef存储资源实例，避免每次渲染时重新创建。
• 确保副作用可重复执行且可清理：即使在StrictMode下被多次调用，清理函数能正确释放资源，不会导致泄漏或异常。
• 全局共享的长连接，建议通过Context API或状态管理库统一管理，让多个组件共享同一实例，避免重复创建。

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