HTML中WebSocket的心跳机制保持长连接不超时断开的方案-html教程-PHP中文网

浏览器不支持原生 ping/pong 帧，必须用应用层心跳：客户端定时发{"type":"ping"}、服务端毫秒级回{"type":"pong"}，配合双定时器与服务端lastactive检测，才能可靠保活。

html中websocket的心跳机制保持长连接不超时断开的方案

浏览器根本不支持原生 ping/pong 帧控制

你无法调用 ws.sendPing()，也监听不到 onping 或 onpong 事件——W3C 规范明确禁止 JavaScript 暴露 WebSocket 协议级的 Ping/Pong 控制帧。所有声称能直接操作底层心跳的代码，在 Chrome、Firefox、Safari 中都会报错或静默失败。

浏览器只会自动响应服务端发来的 Ping（回 Pong），但你既不能触发它，也无法感知这个过程。这意味着：
• readyState 可能还显示 OPEN，但后续 ws.send() 已静默失败
• 仅靠服务端设置 pingTimeout（如 Node.js ws 库）无法让前端主动判断断连
• 依赖“浏览器自动回 pong”等于放弃超时判定能力

必须用 JSON 消息模拟心跳，且间隔要卡死中间设备阈值

真实可用的心跳是应用层协议：客户端定时发 {"type":"ping","ts":Date.now()}，服务端立即回 {"type":"pong","ts":Date.now(),"from":"server"}。关键不是格式像不像，而是能否双向探测活性。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

Nginx 默认 proxy_read_timeout 是 60s，心跳间隔建议设为 40s（2/3 阈值），不能设成 45s 或 50s —— 边界抖动极易断连
运营商 NAT 超时通常为 30–120s，若你走的是移动网络，保守起见心跳别超过 25s
RabbitMQ STOMP 插件默认服务端超时是 10s，此时心跳必须 ≤8s，且 payload 得是纯文本 "ping"，发 JSON 会直接断连
心跳内容必须带 type 字段，避免和业务消息混淆；服务端收到后必须跳过鉴权、日志、DB 写入等耗时逻辑，毫秒级响应

客户端必须配双定时器：发 ping + 等 pong

只发不等 = 白发。常见错误是用 setInterval(() => ws.send("ping"), 30000)，结果一次丢包就导致后续全链路失联，但前端毫无感知。

每次发 ping 前必须校验 ws.readyState === WebSocket.OPEN，否则 send() 抛错且不触发 onerror
发完立刻启动 setTimeout 监控响应，比如 10s 内没收到 type === "pong" 就 ws.close(4001, "heartbeat timeout")
收到任意 type === "pong" 或业务消息时，都要 clearTimeout 当前响应计时器 —— 否则一次延迟就会误判
页面切后台时，setInterval 在 iOS Safari 上可能冻结，Android Chrome 也会节流；改用 setTimeout 链式调用更可靠：ws.send(...); heartbeatTimer = setTimeout(startHeartbeat, 40000);

服务端必须记录 lastActive 并主动踢僵尸连接

光客户端发 ping 没用。服务端不配合，连接照样堆积成僵尸。

连接建立时，用 Map 存储 socket 实例和 lastActive 时间戳（别挂 socket.lastActive 上，易内存泄漏）
每次收到 ping 或任意业务消息，都更新对应时间戳
启动独立定时任务（如每 25s 扫描一次），对 Date.now() - lastActive > 90000 的连接调用 socket.terminate()（比 close() 更彻底）
务必监听 socket.on("close") 和 socket.on("error")，及时从 Map 中删除对应项