SharedWorker实现长连接共享，降低服务器压力

SharedWorker 通过让同源多页面共享单个 WebSocket 连接，实测可降低服务端并发连接数达92%，成为缓解高并发长连接压力最直接有效的手段；但其威力依赖严格前提——必须运行在 HTTPS 或 localhost 环境、Worker 脚本与页面同源、WebSocket 在 Worker 内创建且由 Worker 统一管理状态，并通过 clientId 与 port 生命周期强绑定实现精准消息路由，否则极易引发静默失效、重连雪崩或数据错乱等隐蔽线上故障。

SharedWorker 本身不能直接降低服务端连接并发压力上限，但它能显著减少客户端向服务端发起的重复 WebSocket 连接数——这是缓解服务端连接压力最直接、最可控的手段。

为什么 SharedWorker 能压降服务端连接数

浏览器对同源页面默认不限制标签页数量，但每个页面若独立 new WebSocket()，就会建立一条 TCP 连接。100 个标签页 = 100 条长连接，服务端需维护 100 个 socket 文件描述符（fd）。SharedWorker 的核心价值在于：它让这 100 个页面共享 一个 WebSocket 实例。

• SharedWorker 实例在同源所有页面间唯一存在，只要至少一个页面存活，Worker 就持续运行
• WebSocket 必须在 SharedWorker 内创建（new WebSocket()），不能由页面调用 —— 否则页面一刷新/崩溃，连接就断
• 服务端看到的只是 1 个客户端 IP + 1 个连接，而非 N 个
• 实测数据：某电商后台从单页 WebSocket 改为 SharedWorker 统一管理后，同用户多开场景下服务端并发连接数下降 92%

必须满足的硬性前提条件

SharedWorker 不是“开了就能用”的功能，任何一步不合规，整个机制会静默失效（连 onerror 都不触发）：

• 协议必须是 https:// 或 http://localhost:port —— file://、http://127.0.0.1、http://example.com 全部被浏览器拒绝
• SharedWorker 脚本路径必须与页面同源（origin 完全一致），子路径不影响，如页面在 /admin/dashboard，Worker 脚本可放在 /js/socket-sw.js
• Worker 内不能使用 localStorage、fetch、XMLHttpRequest，仅支持 WebSocket、postMessage、setTimeout 等基础 API
• 页面首次通信必须调用 port.start()，否则 Worker 收不到消息；且需在 onconnect 回调中立即调用 port.start()

如何避免重连雪崩和服务端频控

如果重连逻辑写在页面里，100 个标签页同时崩溃再恢复，会瞬间向服务端发出 100 次重连请求 —— 大部分服务端会直接触发限流或连接拒绝。正确做法是把全部状态控制下沉到 SharedWorker 内部：

• 连接状态（ws.readyState）只在 Worker 内维护，页面只发指令（如 { type: "send", data: {} }）
• 重连使用指数退避：1s → 2s → 4s → 8s…，上限设为 30s，用 setTimeout 实现（不用 setInterval 防止堆积）
• 心跳必须由 Worker 单点发起：setInterval(() => ws.send("ping"), 30000)，页面切后台也不中断
• 每次 ws.onopen 后，主动广播一次 { type: "connected", timestamp: Date.now() } 给所有页面，避免页面自行轮询判断
• 服务端需配合识别 “单客户端多标签” 场景：Worker 发送的消息里带 clientId（页面生成并首次上报），服务端据此做 topic 订阅路由，而非按连接维度广播

消息路由错乱是最隐蔽的线上故障点

SharedWorker 收到多个页面发来的 postMessage，但无法天然区分来源 —— 如果不做隔离，A 页面发的请求可能被响应给 B 页面，导致数据错乱。这不是理论风险，而是高频线上问题：

• 每个页面必须在 port.start() 后，立刻发送唯一 clientId（推荐用 crypto.randomUUID()，不要拼接 Date.now()）
• Worker 内用 Map 缓存 clientId → port 映射，并在每次 port.postMessage() 前校验该 port 是否还有效（port.closed === false）
• 页面关闭前必须主动发 { type: "disconnect", clientId: "xxx" }，Worker 清理映射；否则残留映射会导致后续消息投递失败
• 不要依赖 self.clients.matchAll() 获取活跃页面 —— Chrome 返回空数组是常态，Firefox 行为不一致，不可用于生产

真正关键的不是“怎么连上”，而是“怎么确保每条消息只到该到的地方”。这个映射关系一旦出错，调试成本极高，且现象随机——有时候 A 页面收不到消息，有时候收到 B 页面的数据，必须从设计之初就强制绑定 clientId 和 port 生命周期。

今天关于《SharedWorker实现长连接共享，降低服务器压力》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！