React对接Node.js多用户实时数据同步实现方案咨询

API 探路者

2026-8-29

方案选型建议

针对你「小体量、逻辑简单、要求实时同步」的场景，方案优先级排序是 SSE（仅单向推送场景）> Socket.IO > 短轮询，三个方案的适用边界如下：

短间隔轮询：完全不推荐用来满足你的核心需求。它的问题非常直接：哪怕你设2秒拉一次的间隔，最坏情况下用户也要等2秒才能看到其他用户的修改，肉眼能感知到明显延迟；只要同时在线用户超过10个，每2秒就会有一批查列表的请求打到后端，90%以上的请求查到的结果和上一次没有区别，纯浪费服务器资源。唯一能用的场景是你对实时性要求极低（允许10秒以上延迟）、同时在线用户不超过5个，这种情况写setInterval确实快，但不符合你要的「即时看到最新结果」的要求。
Socket.IO：是适配你需求的通用高性价比方案。它基于WebSocket封装，自带自动重连、降级兼容（连不上WebSocket会自动转长轮询）能力，你应用体量小的话，后端单实例就能轻松扛住几百个同时在线用户，资源占用比轮询低一个量级，实时性是毫秒级的。
Server-Sent Events（SSE）：是比Socket.IO更轻量的最优解（如果你的场景满足条件）。如果你的应用只有「服务端把列表变更推给前端」的单向通信需求，不需要双向高频交互（比如协同编辑、实时打字、在线状态同步这类），SSE比Socket.IO代码量更少、传输开销更低：浏览器原生支持EventSourceAPI，不需要额外装客户端依赖，走标准HTTP协议，后端适配成本也极低。唯一缺点是不支持双向通信，鉴权只能靠cookie或URL带参数，不能自定义请求头。

Socket.IO 在React中的正确落地方式

首先纠正两个常见的错误思路：既不要把socket实例直接放进useEffect依赖数组，也不要把首屏数据拉取的逻辑完全封装到socket函数里，两者的职责本来就是拆分的：普通HTTP请求负责拉全量数据，socket只负责做「变更通知器」，不要把两者绑死。
正确实现步骤如下：

单独抽离socket单例，不要在组件内重复初始化
新建单独的工具文件初始化socket，整个应用复用同一个连接，避免每次组件渲染都新建连接导致的连接泄漏：

// src/utils/socket.js
import { io } from "socket.io-client";
const socket = io(import.meta.env.VITE_API_BASE_URL, {
  autoConnect: false, // 手动控制连接时机，避免未登录状态下发起无效连接
});
export default socket;

组件内拆分数据拉取和事件监听逻辑
首屏加载直接走普通fetch/axios请求拉全量列表，不要等socket连接建立后再拿数据，不然socket连接失败时首屏会一直卡在加载态；socket只负责监听后端的变更通知，收到通知后直接重拉全量列表即可——你的应用逻辑简单，直接重拉全量比做增量数据diff省很多事，不容易出bug。
组件示例代码：

import { useEffect, useState, useCallback } from "react";
import socket from "./utils/socket";

export default function SharedList() {
  const [list, setList] = useState([]);
  const [loading, setLoading] = useState(true);

  // 抽离全量列表拉取逻辑
  const fetchLatestList = useCallback(async () => {
    try {
      const res = await fetch("/api/shared-list");
      const data = await res.json();
      setList(data);
    } catch (err) {
      console.error("拉取列表失败", err);
    } finally {
      setLoading(false);
    }
  }, []);

  useEffect(() => {
    // 首屏直接拉数据
    fetchLatestList();
    // 传入鉴权信息后建立socket连接
    socket.auth = { token: localStorage.getItem("accessToken") };
    socket.connect();
    // 监听列表变更事件
    const handleListChange = () => {
      // 收到变更通知直接重拉全量，小应用不用做增量合并
      fetchLatestList();
    };
    socket.on("shared-list:updated", handleListChange);

    // 组件卸载时一定要清理：移除监听、断开连接，避免内存泄漏
    return () => {
      socket.off("shared-list:updated", handleListChange);
      socket.disconnect();
    };
  }, [fetchLatestList]);

  return (
    <div className="list-container">
      {loading ? <div>列表加载中...</div> : (
        <ul>
          {list.map(item => <li key={item.id}>{item.content}</li>)}
        </ul>
      )}
    </div>
  );
}

后端配套逻辑非常简单：不需要写复杂的增量推送逻辑，只要在任意用户提交的列表修改请求执行成功后，给所有当前在线的列表页用户广播一条shared-list:updated事件即可，代码量不到10行，完全匹配你小应用的复杂度。

几个避坑提醒

不要在socket的事件回调里直接依赖闭包里的state做更新，要么用React的函数式state更新，要么像上面示例一样直接重拉全量，避免闭包拿到旧state导致数据错误。
如果选SSE的话，前端逻辑更简单，不需要额外依赖，直接在useEffect里初始化EventSource、监听消息、组件卸载时关闭连接即可，逻辑和socket监听基本一致。
不要为了“省请求”让后端在变更事件里带全量列表数据，小应用里前端收到通知自己拉的逻辑更简单，后端广播的时候不用查库拼数据，耦合度更低，出问题排查也方便。

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