第 19 卷

第 19 / 21 卷日期：2026-01-02

40	//仅异常关闭触发重连（1000：正常关闭，不重连）
41	if (event.code !== 1000) {
42	startReconnect();
43	}
44	});

46	ws.addEventListener("error", (error) => {
47	console.error("连接错误：", error);
48	stopHeartbeat();
49	startReconnect();
50	});
51	}

52 53// 心跳相关函数（startHeartbeat/stopHeartbeat 同前文）

54// ...

55 56// 启动重连

57function startReconnect() { 58// 清除旧重连定时器

59	if (reconnectTimer) clearTimeout(reconnectTimer);
60	//超过最大重连次数，停止重试
61	if (reconnectCount >= CONFIG.maxReconnectCount) {
62	console.error("已达最大重连次数，停止重连");
63	reconnectCount = 0;
64	alert("网络异常，无法连接，请稍后重试");
65	return;
66	}
67	//延迟重连
68	reconnectTimer = setTimeout(() => {
69	reconnectCount++;
70	console.log(`第${reconnectCount}次重连...`);
71	initWebSocket();
72	}, CONFIG.reconnectDelay);
73	}

74 75// 重连成功后登录认证（示例）

76function loginAfterReconnect() {

77	const userId = localStorage.getItem("userId");
78	if (userId) {
79	ws.send(JSON.stringify({ type: "login", data: { userId } }));
80	}
81	}

87} 88stopHeartbeat();

✅ 核心补充要点

心跳机制推荐“客户端主导”：服务端被动响应即可，减少服务端主动检测的资源开销；若服务端

需主动检测，逻辑类似（周期性发送ping，客户端响应pong）；

重连时需避免“重复连接”：务必清除旧的定时器，防止多个重连请求同时发起；
生产环境需结合业务优化：如重连间隔可采用“指数退避”（3秒→6秒→12秒...），减少服务端压

力；重连成功后需同步未接收的消息，保障数据一致性；

防火墙兼容：心跳周期需小于防火墙超时时间（如默认30秒超时，心跳设为25秒），避免被防火墙

主动断开连接。

WebSocket与轮询(Polling) 和长轮询 (Long-Polling) 之间有何区别?

WebSocket、轮询（Polling）、长轮询（Long-Polling）均是解决“客户端与服务端实时通信”的方案，但底层实现逻辑、性能开销、实时性差异显著。核心差异源于“是否建立持久连接”和“通信触

发方式”，具体区别可从多个维度对比，同时需明确各自的适用场景。

一、核心概念快速梳理

• 轮询（Polling）：客户端通过“定时发送HTTP请求”询问服务端是否有新数据，服务端立即响应

（有数据返回数据，无数据返回空），请求完成后关闭连接；

• 长轮询（Long-Polling）：客户端发送HTTP请求后，服务端不立即响应，而是“挂起连接”，直

到有新数据或超时才返回响应，客户端收到响应后立即重新发送请求，保持连接“伪持久”；

• WebSocket：通过一次HTTP握手升级为持久TCP连接，实现客户端与服务端全双工双向通信，服

务端可主动推送数据，无需客户端频繁请求。

二、多维度核心区别（面试必背）

对比维度	轮询（Polling）	长轮询（Long-Polling）	WebSocket
连接方式	短连接，每次请求新建TCP连	伪持久连接，HTTP请求挂起	真持久连接，一次
	接，完成后关闭	直至有数据/超时	续至主动关闭
通信方向	单向（客户端请求→服务端响	单向（客户端请求→服务端响	全双工（客户端与

实时性	差，延迟取决于轮询间隔（如	较好，延迟接近数据产生时间	最优，数据产生后
	1秒间隔则延迟≤1秒）	（仅需等待服务端响应）	送，延迟极低（毫
协议开销	极高：每次请求需携带完整	较高：单次请求开销与轮询一	极低：仅握手阶段
	HTTP头部（数百字节），频	致，但请求次数大幅减少，开	部开销，后续数据
	繁建立/关闭TCP连接（三次	销低于轮询	2-10字节，无连接

握手/四次挥手）

服务端压力	极大：需处理大量重复请求，	较大：挂起连接会占用服务端	极小：单条TCP连
	频繁创建/销毁连接	资源（如线程/进程），高并	个请求，资源占用
		发场景易过载	并发
兼容性	最好：支持所有浏览器和	较好：支持大部分现代浏览	较好：支持IE10+及
	HTTP服务器，无需额外配置	器，需服务端支持连接挂起	浏览器，需服务端

WebSocket协议

实现复杂度	极低：客户端定时发请求，服	中等：服务端需处理连接挂	中等：需处理握手
	务端直接响应，无需特殊处理	起、超时重连，客户端需处理	线重连，前后端协

重连逻辑

三、适用场景对比（面试拓展）

轮询：适用于简单低频次实时需求：如后台数据定时刷新（5分钟一次）、非核心通知推送，开发

成本极低，无需复杂配置；

长轮询：适用于中等实时需求，兼容旧环境：如早期聊天应用、订单状态通知，实时性优于轮询，

且兼容不支持WebSocket的旧浏览器/服务器；

WebSocket：适用于高实时、高并发需求：如在线聊天、实时音视频、在线游戏、股票行情推

送，是目前实时通信的最优方案，性能和体验均最佳。

✅ 核心总结

三者的核心差异在于“是否基于持久连接”和“数据推送主动性”：轮询和长轮询本质仍是HTTP单向通信，依赖客户端主动请求，存在高开销、低实时性的问题；WebSocket通过持久全双工连接实现服

务端主动推送，彻底解决了HTTP在实时通信场景的缺陷。从发展趋势看，WebSocket已成为实时通信的主流方案，仅在需兼容极旧环境时才考虑长轮询/轮询。

讲述一下如何使用WebSocket API实现一个简单的聊天应用。

全站分卷索引 · 21 卷