陆拾贰號做这件事之前，我也以为把消息推送从 HTTP 轮询换成 WebSocket，只是“换一个接口、改一下前端定时器”的事。真正动手之后才发现，协议一变，连接模型、服务端线程模型、网关配置、运维监控、甚至消息丢失时的排查思路全都要跟着重来一遍。这篇文章就围绕我实际改造一个 B 端项目消息推送模块的过程，把 HTTP 和 WebSocket 两种模式下那些“看不到但真实存在”的变化讲清楚，重点是换了之后到底改了什么、为什么改、以及哪些坑是上线后才冒出来的。
1. 改造前，HTTP轮询是怎么把消息“拖”成秒级延迟的
1.1 定时轮询：请求次数和实时性成了死对头
先说最传统的方案。客户端写一个 setInterval，每 3 秒或 5 秒向后端拉一次未读消息、工单状态、告警通知。这个方案最大的问题不在功能，而在资源消耗和实时性的矛盾。
假设一个企业后台有 5000 个在线用户，推送间隔定 5 秒，那么后端每秒钟至少要承受 1000 个 /message/poll 请求。这些请求绝大多数都不会产生真正的推送数据，但每一次都要走完一遍完整的 HTTP 流程：DNS 解析（如果没做长连接复用）、TCP 握手、TLS 握手、HTTP 请求/响应头、服务端查库、序列化 JSON、然后客户端拿到一个空数组。这里面的 CPU、内存、带宽、数据库压力，有一大半是“白干的”。
更难受的是实时性。如果后端某个告警在两次轮询之间到达，客户端最多要等 5 秒才能看到。把轮询间隔从 5 秒改成 1 秒，实时性变好了，但后端请求量直接变成每秒 5000 次，数据库连接池先扛不住。这就是 HTTP 轮询的死结：想快就得增加请求频率，增加请求频率就得烧服务器资源。
1.2 长轮询与 SSE：中间态的妥协
后来有团队改用长轮询（Long Polling），思想是客户端发一个请求，后端没有新消息就挂着不响应，等有消息了再返回，客户端收到后立刻发起下一个请求。这样真正做到了“消息一产生就返回”，实时性比定时轮询好很多。
长轮询的代价是服务端需要维护大量挂起的请求连接。每个挂起连接都会占用一个连接槽位，如果项目用的是 Tomcat 等传统 Servlet 容器，线程池很容易被打满。另一个问题是请求重放：客户端因为网络抖动重发请求时，后端可能同时存在两个相同业务的挂起请求，消息可能被推两次。
SSE（Server-Sent Events）比长轮询更“Web”一点，它是 HTTP 协议上实现的服务端单向推送，客户端用 EventSource 订阅，服务端可以持续吐出数据。SSE 实现简单、自动重连、还有 Last-Event-ID 做断点续传，但它有一个天然的约束：只能服务端往客户端推，客户端想发消息得另走 HTTP 接口。而且 SSE 在 HTTP/1.1 下同样占用一个连接，连接数上来了，代理和浏览器连接上限的限制也一样绕不过去。
1.3 我决定换掉它的真实触发点
我们项目当时用的是“短轮询 + 少量长轮询”的混合方式。真正让我下决心换 WebSocket 的，不是某一次性能压测，而是线上一次告警：某个时段大量用户同时在线，轮询请求量把网关和数据库连接池打到临界值，消息队列里的工单状态更新已经做完了，用户端却迟迟刷不出来。
当时我打开服务端日志一看，一个推送接口 1 秒内被调了几千次，但绝大多数响应都是空数组。这种感觉就像你为了等一封邮件，每 5 秒去小区门口看一次信箱，而 WebSocket 能做到的是：门口装一个门铃，信到了门铃才响。门铃方案需要拉一根专用线（长连接），但一定比所有人每 5 秒跑一趟门口要省力气。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. WebSocket不是“HTTP的升级版”，而是另一套连接模型
2.1 从三次握手到一次升级：连接的生命周期完全变了
很多人误以为 WebSocket 是 HTTP 加了一个新方法，其实不是。WebSocket 的连接建立还是借用了 HTTP 的握手过程：客户端发一个包含 Upgrade: websocket 头的请求，服务端返回 101 Switching Protocols，然后这条 TCP 连接就从 HTTP 协议切换成了 WebSocket 帧协议。
这个“切换”非常关键。握手完成后，客户端和服务端之间不再有“请求-响应”的语义，而是建立了一条全双工的长连接。客户端可以随时发帧给服务端，服务端也可以随时发帧给客户端，双方都不需要再重复握手、重复带一堆 Cookie、重复协商 TLS。对业务层来说，连接的生命周期从“一次一断”变成了“建立后长期持有”，而我们后面所有的改造点，都是围绕这个生命周期展开的。
连接模型的不同，直接影响了服务端的设计思维。HTTP 时代，服务器是无状态的，每个请求进来，处理完就丢，水平扩展非常容易。WebSocket 时代，服务端必须记住“这个连接属于哪个用户”，连接是有状态的，断线、迁移、重连都需要额外处理。这也是为什么很多项目把 HTTP 换成 WebSocket 之后，第一个炸的问题就是实例重启导致所有客户端集体掉线。
2.2 服务端主动推送：实时性不再依赖客户端“来问”
WebSocket 最直接的变化是消息的到达方式从“拉”变成“推”。以前后端产生一条工单状态流转消息，得等客户端下一次轮询来拿；现在后端业务代码里调用一下 session.getBasicRemote().sendText(payload)，客户端只要连接还在，几百毫秒内就能收到。
这个变化带来的不只有“快”，还有业务表达上的简洁。拿“未读消息数”举例，HTTP 轮询时前端需要每 5 秒调一次 GET /unread-count，后端每次都要查库统计。换成 WebSocket 后，后端在消息写入数据库后主动推一条 {"type":"unread","count":12}，前端收到后直接更新角标。数据库从“按固定频率被打扰”变成“只在真正变化时被通知”，查询压力自然降下来。
不过主动推送也带来了一个要时刻提醒自己的问题：服务端现在有了“主动打扰客户端”的能力，消息类型、频率、量级都要做控制。如果业务代码里循环发推送，或者一个状态变更触发了 5 条重复通知，客户端的体验反而比轮询更差，因为这相当于从“5 秒问一次”变成了“1 秒被轰炸 5 次”。
2.3 帧格式和头部开销：为什么同样的推送量，带宽能降下来
HTTP 轮询痛恨消息头。一个普通的 JSON 响应，Content-Type、Cache-Control、Date、Server、Set-Cookie 等头部加起来少则一两百字节，多则四五百字节。如果 5 秒轮询一次，一天下来一个用户光是头部开销就有几十 KB，在线用户一多，这部分就是纯浪费。
WebSocket 的数据帧做了轻量化：一个最普通的文本帧，基础开销是 2 到 14 字节。帧头里只有 FIN、opcode、mask、payload length 这几个关键字段，没有 HTTP 那一大堆重复头。相同业务数据量下，WebSocket 链路传输的额外开销比 HTTP 低一个量级。
当然，这里有一个容易被忽略的细节：WebSocket 不使用 HTTP 头部的各种缓存机制，也没有状态码语义，所以应用层必须自己定义消息类型、状态和错误码。比如推送失败时你是回 {"code":1001} 还是关连接，都得自己在帧里约定。这个“自己定协议”的自由度是把双刃剑，用好了很顺手，设计乱了调试时很痛苦。
2.4 并发模型的变化：从“每请求一线程”到“连接级处理”
HTTP 服务端最常见的模型是同步线程模型：一个请求占用一个线程，处理完释放。轮询请求一多，线程池直接决定服务端的吞吐上限。换成 WebSocket 后，连接是长期占用的，但连接本身不干活，只是在等待事件。真正干活的是连接上触发的事件：收到客户端消息、推送数据出去、连接断开。
所以 WebSocket 服务端通常更适合事件驱动模型，也就是 Netty、Spring WebFlux 这类基于 NIO、Reactor 的框架。连接数可以到几万、几十万，但活跃线程数不会跟着连接数线性增长。项目里如果还是用传统 Tomcat 的阻塞线程模型去扛十万长连接，每个连接占一个线程，内存就先爆了。
我用一个不严谨但容易理解的说法：HTTP 轮询像是银行柜台，每个客户都要占一个柜员，柜员数量决定了能同时接待多少人；WebSocket 更像是一个大厅，大部分人只是坐着等，叫到号才动，所以大厅里能容纳的人数量级完全不一样。但代价是，你必须有“叫号系统”和“等待区管理”，对应到代码里就是连接注册表、心跳检测、超时清理。
3. 动手改造前，必须拍板的几个技术决策
3.1 选原生WebSocket还是STOMP协议
第一个要拍板的是：直接用原生 WebSocket API，还是基于 WebSocket 跑一个子协议（比如 STOMP、MQTT）。
原生 WebSocket 的优势是路径最短，后端一个 @ServerEndpoint，前端一个 new WebSocket()，没有中间层。缺点是消息路由完全靠自己写，客户端发来 {"action":"subscribe","topic":"order"}，你得自己在 onMessage 里做 if-else 转发，连接一多代码就会乱。
STOMP 的好处是它定义了一套基于文本的消息协议，有 SUBSCRIBE、SEND、CONNECT 这些固定命令，Spring 对 STOMP 有非常完整的支持，可以用 @MessageMapping 按目标地址路由消息，还能通过 @SendTo 自动把返回值推给订阅者。它把“谁订阅了什么、消息发到哪个频道”这个能力标准化了。
我的建议是：如果推送逻辑不复杂、就几个固定业务类型，用原生 WebSocket 完全够了；如果业务里有多个角色、多种主题，前端要做频道级别的订阅，那直接上 Spring Boot + STOMP，后续省掉自己造路由轮子的事。我们项目最终选的是原生 WebSocket，因为消息类型少，而且不想让前端再多引入一套 STOMP 客户端库。
3.2 token放哪里：URL参数、首包还是Cookie
WebSocket 握手借用了 HTTP，所以常见的认证方式都有落地空间。但选哪个，直接影响安全性和架构复杂度。
第一种，token 放 URL 参数，比如 ws://api.example.com?token=xxx。实现最方便，Nginx 和网关也容易透传。缺点首先是 token 会出现在访问日志里，有泄露风险；其次是 WebSocket 连接一旦建立，如果 token 过期了，服务端没有办法像 HTTP 一样让浏览器自动重新认证，只能主动断开连接，让客户端带新 token 重连。
第二种，token 放在握手请求的 Authorization 头里。这个在浏览器端受限，因为 new WebSocket() 不允许自定义 HTTP 头。如果改成“先用 HTTP 登录拿到 token，再在连接首包中发送认证信息”，服务端可以先接受连接，然后在第一个文本帧里验证 token，验证不通过再关闭连接。这种方案更灵活，但注意首包认证期间连接已经建立了，不要让未认证连接长时间闲置，要有超时关闭机制。
第三种，通过 Cookie 认证。适合跟 Web 登录态复用，但跨域场景下 Cookie 的属性配置会比较绕。我实际更推荐“HTTP 接口换取临时 token + WebSocket 首包携带认证”的组合，token 有效期可以设短一点，连接建立后再通过心跳续期，安全性比明文 URL 好得多。
3.3 消息体设计：别只想着“把数据塞进去”
HTTP 的接口设计可以靠 URL + Method + 状态码承担一部分语义，WebSocket 只有一条连接，所有消息都靠帧里的内容区分。所以消息体设计比想象中更重要。
我们项目最终统一为这样的格式：
json复制{
"type": "order.status_changed",
"messageId": "8f7c2a1e-9e4b-4b3a-9f51-9b7c0e1a6b2d",
"timestamp": 1737543200000,
"payload": {
"orderId": 1001,
"status": "PAID"
}
}
type 是消息类型，前端根据它决定走哪个处理函数；messageId 用于幂等和追踪，客户端重复收到时可以去重；timestamp 是服务端产生时间，可以用于排查延迟；payload 是真正的业务数据。所有消息必须走这一个壳，不允许直接往连接里塞一个裸字符串。
这样做的好处很直接：第一，前端接入新业务只需要新增一个 type 分支；第二，日志系统里可以按 messageId 全链路追踪；第三，做消息补偿时能精准判断哪一条丢了。协议设计是那种“前期多花十分钟，后期省两小时排查时间”的事。
3.4 网关和负载均衡：不是加个配置就能跑
WebSocket 的长连接和负载均衡之间有天然的冲突。HTTP 请求无所谓命中的是哪台后端，但 WebSocket 连接一旦建立，后续所有帧都必须到达同一台后端实例。如果 Nginx 默认的轮询策略把同一个连接的两个帧分给不同机器，连接直接就断了。
所以网关层必须开启会话保持，常见做法是配置 ip_hash 或基于 Cookie 的 sticky session。Nginx 端还需要注意几个超时参数：
nginx复制map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream ws_backend {
server 10.0.0.1:8080;
server 10.0.0.2:8080;
}
server {
listen 443 ssl;
server_name ws.example.com;
location /ws {
proxy_pass http://ws_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
}
proxy_read_timeout 如果按默认的 60 秒设置，WebSocket 连接空闲超过一分钟就会被 Nginx 切断，客户端表现为“老掉线”。这里的建议是设成比心跳间隔更长的值，比如心跳 30 秒，Nginx 超时 3600 秒。这个配置看着简单，但线上很多“WebSocket 一会儿就断”的诡异问题，根源都是 Nginx 超时没调。
另一个容易踩的坑是后端也设了空闲超时。比如某些框架默认 60 秒内没有数据就关连接，心跳设得再稳，后端自己先动手了也没用。前后端、网关三层的超时参数要放在一起对照检查，缺一个都不行。
4. 改造完成后的真实变化：延迟、请求量、服务器资源
4.1 推送延迟的下降曲线
改造前，前端轮询间隔 5 秒，理论上消息最大延迟就是 5 秒；换 WebSocket 后，我们在后端记录消息产生时间，在前端记录消息接收时间，统计出来的端到端延迟中位数从原来的 2.4 秒降到了 80 毫秒左右。
这个数据背后有一个实际业务影响：以前用户提交一个审批，要等好几秒才能在另一个端看到状态变化，体验反馈是“系统好像卡了”；改造后提交完几乎是瞬间在另外一台设备上弹出来，用户的主观感受完全不一样。对内部系统来说，这种体验升级比单纯省流量更有价值。
4.2 请求量的数量级变化
这是最直观的对比。改造前 5000 个在线用户，5 秒一次轮询，每天仅在轮询接口上的请求量大概在 700 多万次，其中 95% 都是空响应。改造后，每天的 WebSocket 上行消息（包括心跳、业务命令、认证首包）合计只有 30 万次左右，下降了一个数量级以上。
请求量下降带来的连锁反应是：以前高峰期网关要疯狂转发轮询请求，现在网关的压力小了很多；数据库连接池的占用也明显缓解，因为轮询时每次都要查未读数量，现在只有业务数据真正变化时才写一次、推一次。我们后来把轮询用的缓存查询代码删掉了一大部分，服务端逻辑反而更简单了。
4.3 服务器CPU和内存的变化
长连接的服务端资源模型和短连接完全不同，所以不能简单对比“CPU 一定降了”。实测下来，改造后整体 CPU 使用率是下降的，主要原因是没有了大量无意义的 HTTP 请求解析和序列化。但内存占用反而上升了一些，因为每个长连接都需要保存 session 对象、上下文、发送缓冲区。
内存这块有一个优化点：WebSocket 连接对象里不要长期持有大对象。比如有些同学习惯在 session 的 userProperties 里塞一整个用户对象，连接一多，JVM 堆立刻紧张。我们后来只在 userProperties 里放 userId、连接建立时间、最后心跳时间这几个轻量字段，其它业务数据用的时候再到 Redis 里取。
4.4 一套可复用的压测方法
换协议不是拍脑袋的事，最好先压测再上线。我用的压测工具是 JMeter 的 WebSocket Sampler，也可以直接用 Postman 先手动验证连通性，再写脚本做批量连接和推送测试。
压测建议分三步走：
- 第一步，只做连接压力：模拟 1 万个客户端同时建立连接，观察服务端连接数、内存、GC 情况，确认能稳定保持连接。
- 第二步，做推送压力：服务端批量向在线连接推送消息，逐步增加每秒推送条数，观察消息到达率和延迟分布。
- 第三步，做断开重连压力：批量断开连接再重连，观察服务端是否及时释放资源，会不会出现连接泄漏。
压测时重点看两个指标：一个是最大连接数，一个是吞吐与背压。如果服务端推送消息的速度跟不上生产速度，消息会在发送缓冲区里堆积，最终撑爆内存。典型表现是连接还在，但消息延迟越来越大。这个坑在 HTTP 轮询时代不存在，因为客户端请求不过来时直接返回错误就行；WebSocket 长连接建了之后不会主动提示“我扛不住了”，只能靠应用层做限流和丢弃策略。
5. 上线后踩过的坑：心跳、重连、消息丢失与多实例广播
5.1 心跳机制：你没设ping/pong，连接就会“假活”
WebSocket 协议本身有 Ping/Pong 帧，但浏览器端的 WebSocket API 不暴露发送 Ping 帧的能力，所以实际项目里通常用业务层心跳：客户端定时发送 {"type":"ping"}，服务端返回 {"type":"pong"}。
不做心跳最典型的问题是什么？运营商网络和云厂商的负载均衡设备会清理长时间空闲的 TCP 连接。你在服务端看到的连接还在，但这条连接可能已经被中间设备判定为死连接了，数据根本发不过去。这就是“假活”连接。
心跳间隔我建议设 30 到 45 秒，太频繁会白白增加上行流量，太稀疏又起不到保活作用。服务端还要做另一件事：记录每个连接最后收到任何帧的时间，启动一个定时任务扫一遍，超过 90 秒没有收到任何帧的连接直接主动关闭。这个“任何帧”的判定很重要，因为客户端可能只发了业务消息，没发心跳，不能因为心跳缺失就把正常连接误杀。
5.2 断线重连不是重连就完事，消息补偿才是核心
WebSocket 连接断开是常态，网络抖动、手机切 WiFi、后端发布重启、Nginx 超时，都可能让连接悄悄断掉。前端必须做自动重连，这是基本操作。
但重连之后最尴尬的问题是：断开期间的消息丢了怎么办。HTTP 轮询时代，每次请求都是拉最新状态，断几分钟恢复了重新拉一遍，天然有“对账”能力。WebSocket 是推模式，断开时就没人推了，重连后服务端也不会自动知道你上次收到哪条消息。
我们的方案是引入“离线消息补偿”。客户端在连接建立后，第一件事不是拉取最新页面数据，而是带上自己最后一条已确认的 messageId 调一次 HTTP 接口 GET /message/complement?lastMessageId=xxx，服务端把该 ID 之后产生的消息一次性补推回来。这个过程用 HTTP 而不是 WebSocket，是因为连接刚建立，先走一个可靠的同步请求更稳。
如果不想引入 HTTP 长连接之外的补偿通道，也可以在 WebSocket 首包认证里带上 lastMessageId，服务端校验完认证后先补发未送达消息，再进入正常推送流程。无论哪种，都要保证业务处理是幂等的，因为补推和实时推完全可能重复，前端必须能按 messageId 去重。
5.3 多实例部署时广播怎么搞：Redis Pub/Sub与路由策略
WebSocket 连接是有状态的，一个用户的连接落在哪台实例上是确定的。但业务消息是全局产生的，比如订单服务产生一条状态变更，它可能不知道用户连在哪台实例上，更不会去调用那台实例的推送接口。
所以多实例部署时必须在中间加一层“消息路由”。最常见的方案是 Redis Pub/Sub：后端任意实例收到业务事件后，发布到 Redis 频道，所有 WebSocket 服务实例都订阅这个频道，收到事件后只推给“自己身上”的对应连接。
java复制// 伪代码示意
redisTemplate.convertAndSend("ws:push", message);
// 订阅端
container.addMessageListener((message, pattern) -> {
WsMessage msg = objectMapper.readValue(message.getBody(), WsMessage.class);
// 根据 userId 查本地连接并推送
Session session = sessionHolder.get(msg.getUserId());
if (session != null && session.isOpen()) {
session.getAsyncRemote().sendText(json(msg));
}
}, new PatternTopic("ws:push"));
用 Redis Pub/Sub 的缺陷是消息不持久化，如果 Redis 在推送过程中重启，消息就丢了。要求高一点可以换成 Redis Stream 或 MQ，先用 MQ 做可靠投递，再在消费者里转发给 WebSocket 连接。我们项目初期用 Pub/Sub 足够，后来流量大了以后再迁到 MQ，属于按需演进，没必要一上来就上重型中间件。
5.4 连接数监控与告警，别等挂了才看
HTTP 服务我们习惯看 QPS、RT、错误率，这些指标对 WebSocket 并不完全适用。WebSocket 服务最核心的指标是连接数、连接成功率、重连率、消息堆积量、单连接推送延迟。
我们的监控分两部分。一部分是服务端指标采集，每隔一分钟把当前连接数、每个连接的 userId、最后活跃时间写入日志或 Prometheus；另一部分是业务层告警，比如连接数突然下跌 20%，基本可以断定服务端刚发布过或网络层出问题了，需要立刻检查。我们还接入了一个内部告警系统，通过类似“企业微信机器人”的推送通道把异常通知发到运维群里，实话说，这个环节在 HTTP 改造前我完全没考虑过，上线后才发现它的重要性不亚于功能本身。
另外注意一点：监控不只为了“服务挂了知道”，更是为了观察连接的质量。比如重连率长期偏高，一定是网络或心跳配置有问题；消息推送延迟出现锯齿状，就要看是不是有 GC 停顿或 Redis 消费延迟。
6. 什么业务不建议盲目切WebSocket
6.1 实时性要求不高的业务，轮询反而更省事
WebSocket 不是万金油。如果你的业务是“10 分钟内看到新消息就行”，完全没必要维护几十万条长连接。比如每天定时的报表生成、任务状态刷新、后台日志展示，用 30 秒轮询一次，开发量小、运维简单、排查问题直观，用户体验也没有任何损失。
我见过有的项目为了“技术先进”把只有几百个用户的小后台也从 HTTP 改成 WebSocket，结果业务代码全重写，网关配置调了一周，收益几乎为零。技术的价值在于匹配业务场景，不在于协议新旧。
6.2 服务器单向推送场景，SSE可能更合适
如果你的需求只是“服务端主动给客户端推通知”，客户端不需要也不会上行实时消息，SSE 是更轻的选择。SSE 基于 HTTP，天然兼容现有网关，不需要额外处理升级协议；自带自动重连和断点续传；在浏览器里的 API 也比 WebSocket 简单得多。
WebSocket 适合的是双向实时交互，比如协同编辑、在线客服、实时白板、行情推送等场景。单向场景硬上 WebSocket，等于为了送货专门修了一条高速公路，其实普通快递车走省道就够用了。
6.3 移动端公共网络环境下的长连接挑战
如果目标用户大量使用移动网络，WebSocket 长连接会面临一个现实问题：移动网络下连接极不稳定，切换基站、锁屏、App 前后台切换都可能导致连接断开。很多 App 的做法是 WebSocket 只用于前台活跃时的实时通道，到后台就主动断开，靠系统推送服务唤醒，回到前台再重新建立长连接。
这给后端带来的思考是：必须设计好“连接存在但用户不在前台”的状态管理。比如用户锁屏 30 分钟，连接断开了，服务端要把该用户标记为离线，消息进入离线队列，等用户重连后再补偿。如果你没有离线消息体系，WebSocket 在移动端的体验可能比轮询还差，因为用户每次重新打开 App 都会发现消息少了。
6.4 选型决策清单
整理一个简单的判断清单，当有人再问“要不要换 WebSocket”时，可以直接对照：
- 需要服务端主动推送且实时性要求小于 2 秒，才值得引入 WebSocket。
- 客户端只在页面打开时接收消息，关闭页面就无所谓，优先考虑 SSE 或轮询。
- 有双向交互需求，才考虑 WebSocket 的基础架构投入。
- 团队有能力维护长连接监控、离线补偿、连接路由，否则可能被运维问题拖垮。
- 先跑灰度，不要一次性把所有业务切过去。
这个清单可以帮我们挡住大部分不合理的需求，把力气花在真正需要实时性的业务上。
我个人的实操体会是，HTTP 到 WebSocket 的切换，真正难的不是写代码，而是思维模型的切换：你不再处理“一个个请求”，而是在维护“一条条活着的通道”。通道需要心跳、需要补偿、需要被监控，任何一条通道死掉都要有感知、有恢复手段。如果你已经做好了这些心理准备，那 WebSocket 给你带来的实时性和资源收益，确实值得折腾一次。