WebSocket心跳必须主动发ping并校验pong响应，因onClose在微信小程序切后台或H5休眠时不可靠；需统一响应格式、用setTimeout链式调用、设置超时重连及平台保活策略。
uni-app 里 WebSocket 心跳检测不能只靠 onClose，必须主动发 ping 并等待 pong 响应，否则微信小程序会静默断连、H5 页面休眠后不触发回调。
为什么 onClose 不可靠
微信小程序在切后台或页面不可见时，onClose 根本不会触发，连接直接被系统静默回收；H5 端虽能触发，但若浏览器标签页休眠，onClose 可能延迟数秒甚至完全丢失。这意味着你无法依赖它来判断“是否还连着”。
- 所有平台都必须自己发心跳，不能等断连才处理
- 心跳不是发完就完，关键要确认服务端真的收到了、并返回了可识别的响应
- 微信小程序需额外监听
onHide/onShow，在onHide中手动close连接，避免残留无效实例
uni.sendSocketMessage 发心跳的正确姿势
很多开发者直接用 send 发字符串 "ping"，但服务端可能没按约定返回 "pong"，或者前端没做 JSON 解析就比对 data.type，结果永远收不到匹配。
- 统一约定服务端心跳响应为纯文本
"pong"（最简单）或固定结构{"op":"pong"}，避免嵌套字段干扰 - 前端收到
onMessage后，先JSON.parse(res.data)再取op或直接比对字符串，别漏这步 - 不要用
setInterval发心跳：重连时旧定时器未清除，会导致多个心跳并发发送 - 改用
setTimeout链式调用，每次发完立刻设下一次，确保只有一个定时器活跃
心跳超时与重连怎么配合
心跳间隔和超时时间必须和服务端协商好，光客户端设 30s 发一次 ping，服务端却只等 25s 就断，照样掉线。
- 推荐客户端心跳间隔设为
30000（30 秒），服务端ping_timeout设为45000（45 秒），留出网络抖动余量 - 发完 ping 后，立即启动一个
5000毫秒的setTimeout等 pong；超时未收到就socketTask.close()并触发重连 - 重连前先调用
uni.getNetworkType，返回none时不尝试，避免无效请求 - 重连次数限制为 5 次，第 6 次起用指数退避（1s → 2s → 4s → 8s），防止打爆服务端
App 端后台心跳保活的特殊处理
iOS 和 Android 在真后台下，JS 定时器和网络请求大概率被系统终止，前端逻辑做的心跳基本无效。
- iOS 必须在
manifest.json的ios节点配"usesBackgroundModes": ["audio"]，否则进后台 30 秒内必断 - Android 需引导用户关闭厂商省电优化（华为/小米/OPPO），否则进程被强杀
- 低电量时调用
uni.getBatteryInfo判断，把心跳从 30s 降频到 2min 一次 - 真后台场景下，别指望 JS 定时器——改用
plus.push.addEventListener('click', ...)或云函数查“最后活跃时间”兜底
真正难的不是写几行 send 和 setTimeout，而是把心跳响应校验、平台差异处理、后台保活策略、重连节流这些点串成一条闭环逻辑。漏掉任意一环，长连接在某个平台或某种场景下就会悄无声息地失效。
