企业官网建设流程全解析

Socket.IO + Vue 3 的组合在实时通信场景里非常常见，从聊天室、实时通知到协作工具、数据大屏，基本都能看到这两个技术的身影。Socket.IO 本身封装了 WebSocket 的细节，自动处理断线重连、降级轮询这些问题，Vue 3 则提供了响应式系统和组合式 API。这个组合能解决什么问题？最直白的说法：当你的页面需要「服务端主动推数据」而不是一直靠前端轮询的时候，就是 Socket.IO 上场的时候。你不需要自己维护长连接的状态机，不需要反复造轮子实现心跳和重连，只要把事件收发逻辑理清楚，就能在很短的时间内跑通一条完整的实时通信链路。这篇文章适合刚接触实时通信的前端开发者，也适合后端想快速搭一个消息推送服务的同学参考，我会从选型思路讲到完整 Demo，最后把实际项目中踩过的坑全部摊开。

1. 整体设计与思路拆解

1.1 为什么选 Socket.IO 而不是原生 WebSocket

先聊聊选择问题。很多人会问，浏览器内置了 WebSocket API，为什么还要引入 Socket.IO 这个库？

原生 WebSocket 的问题在于，它只处理了传输层协议，业务里最头疼的那些事情它一概不管：

• 断线重连需要自己实现，而且重连策略（退避算法、重试次数限制）写起来非常繁琐
• 连接状态管理要自己做，什么时刻连接建好、什么时候断开、什么时候异常，都需要手动监听
• 房间（Room）和广播（Broadcast）机制没有，多客户端消息分发全靠自己设计
• 中间代理层对 WebSocket 的支持参差不齐，某些老旧网络环境需要回退到轮询

Socket.IO 把这些全部打包了。它自带心跳机制（ping/pong），自动检测连接是否健康，断线之后有默认的重连逻辑，服务端天然支持房间概念，还能广播消息。最实用的一点是它的降级机制——当 WebSocket 信道不可用时，自动转到 HTTP 长轮询，业务代码完全不用改。

注意：Socket.IO 不是 WebSocket 的替代品，而是基于 WebSocket 之上的一套实时通信框架。它优先使用 WebSocket 传输，失败时自动降级到其他传输方式。理解这点后，很多配置选项你就能看懂了。

1.2 Vue 3 项目里接入 Socket.IO 的架构选择

Vue 3 这边要决定的是：怎么把 Socket.IO 客户端实例融入到组件体系里。

常见的做法有三种：

做法一：在单个组件里直接用

单文件组件里直接 import socket.io-client 创建连接，销毁时关闭。适合只有一个页面需要实时通信的场景，比如某个独立的图表大屏页。

做法二：封装成独立的模块（推荐）

把 Socket.IO 连接逻辑抽出来，放到src/services/socket.js里，导出连接实例。组件里按需引用。这个方案的优点是连接只初始化一次，全局共享一个长连接，不会因为组件切换导致连接反复创建销毁。

做法三：用 Pinia/Vuex 管理连接状态

对于需要跨组件共享连接状态、消息数据的场景（比如全站通知、聊天消息列表），把 socket 实例和数据都放进全局状态管理。组件只读写 store，不直接触碰 socket。

我实际项目里用下来，绝大多数场景选做法二就够了，做法三会让简单项目变得繁琐。其实你自己定义好事件处理逻辑后，配合组合式 API 可以做到很优雅。

2. 环境准备与依赖安装

2.1 项目基础环境要求

在做 Socket.IO + Vue 3 集成之前，先确认环境：

• Node.js 版本：建议 18.x 以上（16.x 也能跑，但有些依赖的构建工具在旧版本上会警告）
• npm 版本：建议 9.x 以上
• 已有 Vue 3 项目：可以是 Vite 构建的，也可以是 Webpack 构建的（这里以 Vite 为例，因为现在新项目基本都是 Vite 起步）

如果还没有项目，直接一行命令创建：

npm create vite@latest socket-demo -- --template vue cd socket-demo npm install

2.2 安装 socket.io-client

Vue 3 项目里需要的是客户端库，注意别装错包了——服务端是socket.io，客户端是socket.io-client，这是两个不同的 npm 包。

npm install socket.io-client

这里有个非常关键的版本问题：socket.io-client 分为 2.x 和 4.x 两个大的版本线，它们与服务端的协议不兼容。如果你的服务端用的是 socket.io 3.x/4.x，客户端必须也用 4.x；如果服务端是 2.x，客户端得用 2.x。现在新项目直接用 4.x 就好。

我先说清楚：这篇文章默认你服务端用 socket.io 4.x，客户端用 socket.io-client 4.x。版本对不上会出各种诡异的问题，比如连接上了但事件触发不了、触发一次却收到两遍——这些我后面会专门在问题排查里讲。

2.3 服务端依赖安装

服务端可以是独立的 Node.js 服务，也可以结合 Express 一起用，甚至可以用在已有的 Nest.js 项目里。最标准的搭配是 Express + Socket.IO：

npm install express socket.io

提示：客户端和服务端不需要在同一个项目里。实际项目里它们往往是两个不同的服务，只是开发阶段为了方便演示会放一起跑。部署时客户端打包成静态资源，服务端跑 Node 进程，另外还需要注意跨域的处理方式。

3. 服务端搭建与核心配置

3.1 最小的 Socket.IO 服务端

先写一个最基础的服务端，把连接建立、断开、自定义事件收发跑通：

// server/index.js const express = require('express'); const http = require('http'); const { Server } = require('socket.io'); const app = express(); const server = http.createServer(app); const io = new Server(server, { // 开发阶段允许跨域，生产环境要收敛 cors: { origin: ['http://localhost:5173'], methods: ['GET', 'POST'] } }); // 连接事件 io.on('connection', (socket) => { console.log('客户端已连接：', socket.id); // 客户端发来消息，服务端处理后再广播回去 socket.on('chat:message', (payload) => { console.log('收到消息：', payload); io.emit('chat:message', { ...payload, serverTime: Date.now() }); }); // 断线事件 socket.on('disconnect', (reason) => { console.log('客户端断开：', socket.id, '原因：', reason); }); }); server.listen(3000, () => { console.log('Socket.IO 服务已启动：http://localhost:3000'); });

这里的关键点：

• new Server(server, options)必须传入 HTTP Server 实例，不能直接在 Express 的 app 上跑
• 跨域配置的 origin 要写前端的源（协议 + 域名 + 端口），开发阶段前端 5173 端口（Vite 默认），服务端 3000
• connection事件回调里拿到的socket对象，是服务端给每个客户端创建的唯一连接通道

3.2 命名空间与房间的选用

Socket.IO 有两个从设计上就内置的分组机制：命名空间（Namespace）和房间（Room）。

命名空间：相当于创建了多个独立的 Socket.IO 服务实例端点。例如/chat和/notification是两套互不干扰的通道，消息广播互不影响。适用于业务域划分明确的场景。

const chatNsp = io.of('/chat'); const notifyNsp = io.of('/notification'); chatNsp.on('connection', socket => { // 只有连到 /chat 的客户端会到这里 }); notifyNsp.on('connection', socket => { // 只有连到 /notification 的客户端会到这里 });

房间：在同一个命名空间内，把若干个 socket 连接分到一个组里，只给这个组广播消息。典型场景是聊天室——每个聊天室就是一个房间。

// 加入房间 socket.join('room-001'); // 只给 room-001 的房间广播 io.to('room-001').emit('room:message', payload); // 离开房间 socket.leave('room-001');

我个人的建议是：不管是命名空间还是房间，都按业务边界去划分，别把两者混用。比如全局通知用独立命名空间，聊天用房间，这样事件逻辑清晰得多。特别是当你的项目后续要加功能时，命名空间隔离的好处会越来越明显。

3.3 中间件与鉴权拦截

很多项目在建立连接时就需要带上用户身份信息。Socket.IO 提供了中间件机制，在connection事件触发之前执行：

io.use((socket, next) => { const token = socket.handshake.auth?.token; if (!token) { return next(new Error('未登录，不允许建立连接')); } // 这里解析 token，把用户信息挂到 socket 上 socket.userId = parseToken(token); next(); });

客户端建立连接时可以这样传 token：

const socket = io('http://localhost:3000', { auth: { token: localStorage.getItem('token') } });

next()不带参数就放行，带 Error 就拒绝连接。客户端会触发connect_error事件，你可以在这里提示用户登录失效。

重点提醒：Socket.IO 中间件里的鉴权只是校验连接是否合法。服务端在每个事件处理里还得再校验一次权限，尤其是涉及业务数据读写的事件。理由是连接一旦建立，如果 token 过期了、用户被踢下线了，已经建立的连接并不会自动销毁，你得在业务层面处理这些情况。

4. Vue 3 客户端接入：从连接到完整封装

4.1 创建 Socket 连接实例

Vue 3 项目里，我习惯把 Socket.IO 的创建逻辑集中到一个独立模块，避免每个组件都写一遍连接初始化。

// src/services/socket.js import { io } from 'socket.io-client'; const URL = import.meta.env.VITE_SOCKET_URL || 'http://localhost:3000'; // 单例连接 let socket = null; export function getSocket() { if (!socket) { socket = io(URL, { transports: ['websocket'], autoConnect: false, // 由业务代码显式控制连接时机 reconnection: true, reconnectionAttempts: 5, reconnectionDelay: 1000, reconnectionDelayMax: 5000, timeout: 20000 }); } return socket; }

这里每个配置项都值得说一下：

• autoConnect: false表示先创建实例但不自动建立连接，等登录完成后、明确需要才开始连接。好处是避免页面刚加载时就发连接请求，后端还没拿到有效的身份凭据
• transports: ['websocket']强制只走 WebSocket 通道。如果部署环境明确没有兼容性问题，这种方式最省资源；如果网络环境复杂，不要限制，让 Socket.IO 自己降级
• reconnectionAttempts: 5与reconnectionDelay: 1000规定了断线重连的节奏。默认重试次数是无限次，生产环境建议限制成可观的次数，避免后端宕机后客户端无意义地重试刷流量

4.2 用组合式 API 封装事件绑定

Vue 3 的组合式 API（Composition API）很适合封装 Socket.IO 的订阅逻辑。核心思路：把「建立监听、处理消息、清理监听」做成一个可复用的函数。

// src/composables/useSocketEvent.js import { onMounted, onUnmounted } from 'vue'; import { getSocket } from '@/services/socket'; export function useSocketEvent(eventName, handler) { const socket = getSocket(); onMounted(() => { socket.on(eventName, handler); }); onUnmounted(() => { socket.off(eventName, handler); }); }

然后在组件里这样用：

<script setup> import { ref } from 'vue'; import { useSocketEvent } from '@/composables/useSocketEvent'; const messages = ref([]); // 订阅消息事件 useSocketEvent('chat:message', (payload) => { messages.value.push(payload); }); // 订阅连接状态变化 useSocketEvent('connect', () => { console.log('连接建立成功'); }); // 订阅断线 useSocketEvent('disconnect', (reason) => { console.log('连接断开：', reason); }); </script>

为什么要封装成 composable 而不是直接在组件里socket.on(...)？

我在真实项目里踩过的坑：组件销毁时不记得解绑监听，导致事件被重复触发。具体表现是——你从聊天页面跳到别的页面再跳回来，消息会收到两遍、三遍甚至更多遍。原因就是每次进入组件都注册了一次on监听，老监听还没被清掉。用useSocketEvent这个封装，onUnmounted自动off，从根上杜绝这个坑。

4.3 连接状态与 Vue 响应式的联动

一个很常见的需求：页面上实时显示连接状态（已连接 / 断线重连中 / 已断开）。Socket.IO 的事件是异步的，把这些状态同步到 Vue 的响应式数据上，需要一个统一的状态管理点。

我提供一个简单方案——用一个模块级别的响应式状态：

// src/services/socketState.js import { ref } from 'vue'; export const connectionState = ref('disconnected'); // connecting | connected | disconnected | reconnecting export const lastError = ref(null);

在连接管理的模块里统一更新：

socket.on('connecting', () => { connectionState.value = 'connecting'; }); socket.on('connect', () => { connectionState.value = 'connected'; }); socket.on('disconnect', () => { connectionState.value = 'disconnected'; }); socket.on('reconnect_attempt', () => { connectionState.value = 'reconnecting'; });

组件里直接用：

<script setup> import { connectionState } from '@/services/socketState'; </script> <template> <div class="connection-badge"> {{ connectionState === 'connected' ? '在线' : '离线' }} </div> </template>

因为ref创建的状态是全局的、响应式的，任何组件 import 它都能拿到最新的值，UI 自动更新。这比每个组件内部维护自己的布尔变量要省心得多。

4.4 消息接收与 Vue 响应式的注意事项

Socket.IO 事件回调里更新 Vue 响应式数据时，有一个容易踩的坑：如果是用reactive创建的对象去接收数据，数组或者对象的深层改动可能不触发界面刷新。

import { reactive } from 'vue'; const state = reactive({ messages: [], unreadCount: 0 }); // 回调里更新 socket.on('chat:message', (payload) => { state.messages.push(payload); state.unreadCount += 1; });

大部分常规操作reactive都能追踪到。但如果你是从一个普通数组赋值给state.messages，比如：

socket.on('batch:history', (list) => { state.messages = list; });

这个也没问题，因为state.messages是state的属性，整个替换属性会触发响应式更新。

真正容易出问题的是：你在回调里直接修改了socket或其他非响应式对象的数据，然后又让组件去读它。比如：

let messageCache = []; // 非响应式 socket.on('chat:message', (payload) => { messageCache.push(payload); // 这里改了，但组件感知不到 });

这种场景要用ref或者reactive包一层才能让组件感知到。记住一个原则：Socket.IO 回调里无论拿到什么数据，最终都要写入 Vue 的响应式容器才能驱动 UI。

5. 完整实战：一个多端实时聊天 Demo

5.1 功能拆分与数据结构设计

光讲配置太干，我们直接上一个能跑的聊天 Demo。功能需求锁定在三块：

• 用户输入昵称进入聊天室
• 实时发送和接收聊天消息
• 在线成员数实时显示

消息结构设计：

{ type: 'chat', // 消息类型，预留 username: '用户A', // 发送者昵称 content: '你好，世界', // 消息内容 timestamp: 1699999999999 // 服务端时间戳 }

这个结构看似简单，但字段命名带有明显的前瞻性：type字段是为了以后扩展图片消息、系统消息、撤回消息时不用改协议。

5.2 服务端完整代码

// server/index.js const express = require('express'); const http = require('http'); const { Server } = require('socket.io'); const app = express(); const server = http.createServer(app); const io = new Server(server, { cors: { origin: ['http://localhost:5173'], methods: ['GET', 'POST'] } }); // 维护在线成员数量 let onlineUsers = new Set(); io.on('connection', (socket) => { // 客户端登录时上报昵称 socket.on('user:join', (username) => { socket.username = username; onlineUsers.add(username); // 广播系统消息 io.emit('system:message', { type: 'system', content: `${username} 加入了聊天室`, timestamp: Date.now() }); // 广播在线人数 io.emit('user:onlineCount', onlineUsers.size); }); // 聊天消息 socket.on('chat:message', (payload) => { io.emit('chat:message', { type: 'chat', username: socket.username || '匿名', content: payload.content, timestamp: Date.now() }); }); // 断开处理 socket.on('disconnect', () => { if (socket.username) { onlineUsers.delete(socket.username); io.emit('system:message', { type: 'system', content: `${socket.username} 离开了聊天室`, timestamp: Date.now() }); io.emit('user:onlineCount', onlineUsers.size); } }); }); server.listen(3000, () => { console.log('聊天服务运行在 http://localhost:3000'); });

服务端逻辑不复杂，核心就是把客户端的上报数据加工后广播出去。我故意把用户当前昵称绑定在socket.username上，而不是让客户端每次发消息都传昵称——这样即使用户中途改了昵称，历史连接上的归属也是正确的。类似这样的设计细节，在多人协作项目里能避免很多来源混乱的问题。

5.3 客户端完整代码

<!-- src/App.vue --> <script setup> import { ref, onMounted } from 'vue'; import { getSocket } from '@/services/socket'; const socket = getSocket(); const username = ref(''); const joined = ref(false); const messages = ref([]); const onlineCount = ref(0); const inputContent = ref(''); function joinChat() { if (!username.value.trim()) return; socket.emit('user:join', username.value.trim()); socket.connect(); joined.value = true; } function sendMessage() { const content = inputContent.value.trim(); if (!content) return; socket.emit('chat:message', { content }); inputContent.value = ''; } onMounted(() => { socket.on('chat:message', (payload) => { messages.value.push(payload); }); socket.on('system:message', (payload) => { messages.value.push(payload); }); socket.on('user:onlineCount', (count) => { onlineCount.value = count; }); }); </script>

注意我在joinChat里手动调用了socket.connect()，因为之前配置把autoConnect关掉了。用户必须输入昵称后才建立连接，否则服务端会收到一堆未注册身份的连接。

模板部分：

<template> <div class="chat-page"> <div v-if="!joined" class="login-box"> <input v-model="username" placeholder="输入昵称进入聊天室" /> <button @click="joinChat">进入聊天室</button> </div> <div v-else class="chat-box"> <div class="chat-header"> 当前在线人数：{{ onlineCount }} </div> <div class="chat-messages"> <div v-for="(msg, index) in messages" :key="index" :class="['message', msg.type]" > <span v-if="msg.type === 'chat'" class="username">{{ msg.username }}：</span> <span v-if="msg.type === 'system'" class="system-content">【系统】{{ msg.content }}</span> <template v-else> <span class="content">{{ msg.content }}</span> <span class="time">{{ formatTime(msg.timestamp) }}</span> </template> </div> </div> <div class="chat-input"> <input v-model="inputContent" placeholder="输入消息..." @keyup.enter="sendMessage" /> <button @click="sendMessage">发送</button> </div> </div> </div> </template>

这个小 Demo 跑通之后，你等于拿到了一个实时通信项目的最小骨架。接下来加「私聊」「已读回执」「消息持久化」都是在现有骨架上扩展。

5.4 启动与联调流程

联调流程有固定的顺序，我建议按这个顺序走：

# 终端一：启动服务端（默认 3000 端口） node server/index.js # 终端二：启动前端（Vite 默认 5173 端口） npm run dev

打开浏览器访问 http://localhost:5173，开两个浏览器标签页（或者用无痕窗口），在两个标签里分别输入不同昵称进入聊天室。然后从一个标签发消息，观察另一个标签是否实时收到。

如果你收到消息正常，说明基础链路已经通了。接着你可以打开浏览器开发者工具，在 Network 面板里过滤 WebSocket（Filter 输入ws），观察连接的帧消息——这里能直观看到 ping/pong 的心跳帧、事件帧的数据格式，对理解 Socket.IO 协议很有帮助。

6. 常见问题与排查实录

6.1 连接一直处于 pending 或直接失败

现象：客户端socket.on('connect')迟迟不触发，Network 面板里 WebSocket 请求一直 pending，最终报错。

排查步骤：

1. 先用接口测试工具直接测试服务端的 WebSocket 接口，确认服务端本身通不通。如果工具也连不上，说明问题在服务端，检查端口是否被占用、进程是否启动
2. 检查跨域配置。浏览器控制台如果有 CORS 报错，说明cors.origin没有准确匹配前端源的协议 + 域名 + 端口
3. 确认客户端连接的 URL 写对了没有。很多人把http://localhost:3000写成了https://localhost:3000，开发环境没有证书，必然连不上
4. 确认版本匹配。服务端是 4.x，客户端是 2.x，握手就会失败。在客户端执行npm ls socket.io-client或者在服务端执行npm ls socket.io查版本

6.2 事件触发了但数据收不到

现象：客户端能看到连接建立成功，但服务端io.emit出来的事件，客户端socket.on没反应。

这个问题的第一大嫌疑就是事件名拼写不一致。Socket.IO 不会对不匹配的事件名报错，它只会静默忽略。我见过项目里chat:message和chat: Message（多了个空格）这种低级笔误，排查了一个下午。

第二大嫌疑是监听注册时机晚于事件发送时机。比如组件已经挂载好了，但代码里先socket.emit('xxx')再socket.on('xxx')，如果服务端同步返回，事件发回来时你还没注册监听，数据就丢了。

// 错误示范：先 emit 后 on socket.emit('get:history'); socket.on('history:list', handler); // 慢了，可能接不到 // 正确做法：先注册监听再 emit socket.on('history:list', handler); socket.emit('get:history');

6.3 收到两条重复消息

现象：同一条消息在界面上出现了两次。

原因基本都在客户端——同一个事件被注册了多次监听。典型路径是：组件 A 里注册了一次socket.on，组件销毁时没清理；后来组件 B 又注册了一次。每次进入页面就多注册一次，消息也就越来越多份。

解决方式就是用前面提到的useSocketEvent封装，让onUnmounted自动清理。如果你不想重构代码，也可以在注册监听时用socket.off(eventName)先清一遍再on：

socket.off('chat:message'); socket.on('chat:message', handler);

注意：off只清理指定事件名的监听，如果你同一事件有多个不同处理器，用off(eventName)会把它们全部清掉。这时候可以用off(eventName, specificHandler)单独移除某个处理器。

6.4 断线重连不生效

现象：网络切换（比如 Wi-Fi 断了重连）、后端重启后，客户端没有自动恢复连接。

先检查配置：reconnection默认是true，但如果你的代码里写成了reconnection: false，断开后就不会重连了。这属于配置失误。

另一个容易被忽略的场景：autoConnect: false的情况下，手动connect()之后如果断开，Socket.IO 还是会按照重连配置来尝试重连。如果你不想让它自动重连，就得调用socket.disconnect()而不是直接断网。

还有一个真实项目里常遇到的问题：服务端重启后，客户端的重连尝试发出时，服务端还没就绪，导致握手失败。Socket.IO 客户端会按退避策略不断重试，这个没问题。但如果你的服务端是多实例部署，客户端连接被负载均衡分到了没有用户 session 的那台实例上，就会出现「连上了但上下文没了」。这种情况需要引入 Redis Adapter 做跨实例的状态同步，这是另一个话题了。

6.5 Vue 组件卸载后还在收到消息

这个问题轻松一点：不是 bug，是设计问题。如果你的 socket 实例是全局单例，连接不会因为组件销毁而关闭，消息事件依然在后台接收，只是没有组件去处理。

这本身是合理行为——你希望连接是全局复用的。但如果消息处理函数访问了已卸载组件的响应式数据，会触发 Vue 的警告。规避方式还是那一条：在onUnmounted里off掉对应的监听处理器，或者确保处理函数里只操作全局状态、不操作组件内部 ref。

6.6 跨域与生产环境连接问题

开发环境跨域靠cors: { origin: [...] }解决。生产环境如果你把前端静态资源和后端放在同一个域名下，就没有跨域问题，只需要把 Socket.IO 服务的路由挂在同域路径下。

如果你前端和后端依旧不同域，生产环境的 CORS 配置要写实际的线上域名，不能用localhost。还有一点：origin: '*'在携带withCredentials（即 cookie 传递）时是无效的，浏览器不会发 cookie 过去。需要明确列出域名。

如果前端通过 Nginx 反代到后端，记得 Nginx 需要配置 WebSocket 升级头：

location /socket.io/ { proxy_pass http://backend:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; }

少了Upgrade和Connection这两行，WebSocket 握手就通不过，Socket.IO 会一直回退到轮询模式，功能虽然能用但性能和实时性差很多。

6.7 常见问题速查表

7. 我在实际接入中总结的几点经验

最后分享几个不写进文档、但在项目里特别管用的经验。

第一，事件命名一定要形成团队规范。我见过用message、new_message、msg:new三种写法表达同一个事件的代码库，排查起来苦不堪言。建议统一用域:动作格式，比如chat:send、chat:receive、user:join、user:leave。

第二，把 Socket.IO 的心跳参数和你的业务超时时间对齐。如果服务端配置了pingInterval: 25000，但你的 Nginx 空闲超时设置成了 60 秒，连接长时间空闲会被 Nginx 掐断。你需要在 Nginx 的proxy_read_timeout里配一个大于心跳周期的时间，一般设成 120 秒以上。

第三，客户端的所有 emit 操作，建议包一层统一的发送函数。别在组件里直接socket.emit('xxx', data)，而是通过一个事件映射模块统一管理，这样当你后续想加消息序号、加签名字段、做发送前校验时，只需要改一个地方。

第四，对连接状态做可视化监控。开发模式下，把 socket 的连接状态实时显示在页面角落，对排查问题有奇效。我之前接手过一个项目，用户反馈消息偶尔收不到，页面右上角显示连接状态是「重连中」，一下子就定位到了网络不稳定的问题。

第五，消息量大的场景务必做分层处理。实时消息全部走 Socket.IO 没问题，但历史消息、批量同步数据建议走 HTTP 接口拉取，不要在建立连接时一次性全量推给客户端。连接时全量推送会让服务端瞬间压力陡增，客户端的响应式渲染也会卡顿。

我踩过一个非常典型的坑：一个实时库存系统，页面打开时服务端把全部库存数据通过 socket 推给新客户端，同时每个库存变更事件也都会广播。结果新客户端一进来，前端被几万条消息瞬间打满，页面直接卡死。后来改成「连接成功后仅推送最近 50 条+ 增量变更事件，历史数据走 HTTP 分页拉取」，问题立刻解决。

如果你之前没接触过 Socket.IO，建议先把这个 Demo 完整跑通，再逐步往自己的业务里迁移。实时通信这块东西，理论再多不如动手跑一遍，遇到问题的时候你才会真正理解重连机制、事件模型、状态同步这些概念的用处。以后你的项目里需要做实时通知、在线协作、大屏数据推送，这套 Socket.IO + Vue 3 的组合会是你最省心的起点之一。