WebSocket实战：从踩坑到稳定实时通信

this.ws = null;
this.reconnectCount = 0;
this.heartbeatTimer = null;
this.isManualClose = false; // 标记是否手动关闭

this.connect();
}

connect() {
try {
this.ws = new WebSocket(this.url);

this.ws.onmessage = (event) => {
try {
const data = JSON.parse(event.data);
this.handleMessage(data);
} catch (e) {
console.error('[WebSocket] 消息解析失败:', e);
}
};

if (!this.isManualClose) {
this.reconnect();
}
};

this.ws.onerror = (error) =>

<

p> {
console.error('[WebSocket] 连接错误:', error);
// onerror之后会触发onclose，所以这里只做日志
};

这个设计真的反人类的地方在于：断开连接的code码多得要命，而且不同浏览器还不一样。比如1000是正常关闭，1006是异常断开，但你永远不知道用户那边会弹出什么鬼code。

另一个坑：断线重连的无限循环

有个用户骂我说：“你们的聊天功能让我手机发烫！”排查后发现是断线重连写了bug，在断网情况下疯狂重连，直接把CPU拉满。

为什么要这样写：重连必须加指数退避，不然就是自杀式攻击。

reconnect() {
if (this.reconnectCount >= this.options.maxReconnectAttempts) {
console.error('[WebSocket] 重连次数已达上限');
this.onMaxReconnectFailed && this.onMaxReconnectFailed();
return;
}

// 指数退避：每次重连间隔翻倍，但不超过30秒
const delay = Math.min(
this.options.reconnectInterval * Math.pow(2, this.reconnectCount),
30000
);

this.reconnectCount++;

// 用setTimeout避免阻塞
setTimeout(() => {
if (document.visibilityState !== 'hidden') { // 页面可见时才重连
this.connect();
} else {
// 页面不可见时，监听visibilitychange
const handler = () => {
if (document.visibilityState === 'visible') {
document.removeEventListener('visibilitychange', handler);
this.connect();
}
};
document.addEventListener('visibilitychange', handler);
}
}, delay);
}

// 心跳检测：防止假连接
sta

rtHeartbeat() {
this.heartbeatTimer = setInterval(() => {
if (this.ws && this.ws.readyState === WebSocket.OPEN) {
// 发送ping消息
this.ws.send(JSON.stringify({ type: 'ping' }));
} else {
this.stopHeartbeat();
this.reconnect();
}
}, this.options.heartbeatInterval);
}

stopHeartbeat() {
if (this.heartbeatTimer) {
clearInterval(this.heartbeatTimer);
this.heartbeatTimer = null;
}
}

消息处理：按类型分派才优雅

很多人收到消息就一个if-else写到天荒地老。我见过一个项目，单个onmessage函数里嵌套了7层switch，看得我头皮发麻。

为什么要这样写：用事件系统解耦，消息来了按类型分派，维护起来爽到飞起。

// 注册消息处理器
on(type, handler) {
if (!this.handlers.has(type)) {
this.handlers.set(type, []);
}
this.handlers.get(type).push(handler);
}

// 移除消息处理器
off(type, handler) {
const handlers = this.handlers.get(type);
if (handlers) {
this.handlers.set(type, handlers.filter(h => h !== handler));
}
}

handleMessage(data) {
const { type, payload } = data;

// 处理ping/pong
if (type === 'pong') return;

// 使用示例
const ws = new WebSocketClient('wss://api.example.com/ws');

ws.on('chat.message', (msg) => {
updateChatUI(msg);
});

性能优化：从3.2秒降到0.8秒的骚操作

我曾经负责过一个弹幕系统，刚开始用WebSocket直接推原始数据，1000人同时在线就卡成PPT。后来优化了三个地方：

1. 二进制传输代替JSON

WebSocket支持ArrayBuffer，可以把数据用二进制格式传输，体积直接减半。

2. 消息去重和节流

相同类型的消息在短时间内合并，别让UI频繁刷新。

add(key, data) {
const existing = this.cache.get(key);
if (existing) {
clearTimeout(existing.timer);
Object.assign(existing.data, data); // 合并数据
} else {
this.cache.set(key, { data, timer: null });
}

this.cache.get(key).timer = setTimeout(() => {
this.flush(key);
}, this.delay);
}

3. 连接池复用

多页面场景下，用SharedWorker或者ServiceWorker共享一个WebSocket连接，避免每个tab都开一条连接。

核心：一张性能对比图，展示优化前后消息延迟和CPU占用率的差异。

生产环境必须做的监控

没有监控的WebSocket就是裸奔。我见过最离谱的事故：某个用户的WebSocket连接因为网络问题变成了半开状态（服务端以为还连着，客户端已经断了），结果服务端一直给这个连接推消息，内存直接爆了。

为什么要这样写：监控就是给系统装个心电图，一眼就能看出哪里有问题。

// 定时上报
setInterval(() => {
this.report();
}, 60000); // 每分钟上报一次
}

recordLatency() {
const start = performance.now();
return () => {
const duration = performance.now() - start;
this.metrics.latency.push(duration);

// 只保留最近100条
if (this.metrics.latency.length > 100) {
this.metrics.latency.shift();
}
};
}

report() {
const avgLatency = this.metrics.latency.length > 0
? this.metrics.latency.reduce((a, b) => a + b, 0) / this.metrics.latency.length
: 0;

console.log('[WebSocket Monitor]', {
...this.metrics,
avgLatency: avgLatency.toFixed(2) + 'ms',
memoryUsage: performance.memory?.usedJSHeapSize
? (performance.memory.usedJSHeapSize / 1024 / 1024).toFixed(2) + 'MB'
: 'N/A'
});

// 告警阈值
if (this.metrics.errorCount > 10) {
alertDevops('WebSocket错误率过高');
}

if (avgLatency > 500) {
alertDevops('WebSocket延迟过高');
}

还有个技巧：优雅处理页面切换

用户切后台的时候，WebSocket还在疯狂推消息，这不仅是浪费带宽，还可能因为移动端网络限制导致连接被强杀。