小程序 TCP Socket 连接教程｜场景限制、心跳与重连设计 – MPForge
直接回答：这是写给小程序开发的 TCP/Socket 长连接教程：实时聊天、设备控制、多人对战这类场景才需要 Socket，接入后必须设计心跳、指数退避重连、轮询降级三件套，并确认后台保活的平台限制。MPForge（DEVDIY 旗下）见过最贵的教训是——把普通请求硬改成长连接，结果断线风暴把服务端拖垮。
一、先确认场景：你真的需要长连接吗
结论先记住：多数小程序业务用请求就够了，长连接只服务「服务端要主动推」的场景。
先过三个判断，再决定要不要引入 Socket：
- 是不是必须服务端主动推？客服聊天、设备状态回传、实时对局是典型场景；普通查询、提交表单用请求更简单可靠。
- 连接数与时长可控吗？用户平均停留几分钟却全程挂着连接，服务端成本远高于收益。
- 有没有降级预案？Socket 连不上时业务还能不能走？没有降级预案的功能不要依赖长连接。
另外要确认平台对连接类接口的使用范围与频次限制，域名同样要在合法域名列表内。弱网下的兜底策略与 小程序弱网离线可用教程 是配套关系，一起设计。
二、心跳与重连：长连接的生命线
没有心跳的长连接是假连接，没有退避的重连是断线风暴。
| 机制 | 达标口径 | 常见错误 |
|---|---|---|
| 心跳间隔 | 按服务器空闲断开时间倒推，取其 1/2~1/3，常用 30~60 秒 | 拍脑袋定 5 秒一次，耗电耗流量 |
| 假死检测 | 心跳发出后超时未收到回应即判定断线，主动关闭重建 | 连接「半死」却一直不重连 |
| 重连退避 | 1s、2s、4s 指数退避加随机抖动，设重试上限 | 失败立即猛连，服务端被打爆 |
| 状态恢复 | 重连成功后补拉断线期间的消息或状态差量 | 重连后直接用旧缓存，数据缺口 |
断线期间的感知口径：界面上明确展示「连接断开，正在重连」状态，而不是假装一切正常；重连成功后用序号或时间戳做差量补拉，把断线窗口内漏掉的消息补齐，避免用户看到凭空消失的记录。
三、接入与验收：从压测到监控
长连接的验收重点是断线率与恢复速度，不是「能连上」。按五步走：
- 确认允许场景：核对平台对 Socket 接口的场景与频次限制，域名与端口配置到位再开发。
- 实现心跳与重连：按第二节口径实现心跳、假死检测、指数退避重连与差量补拉，封装成统一连接层。
- 弱网压测：限速与反复断网环境下验证心跳判死、重连节奏与消息补齐，弱网兜底参考 弱网降级策略。
- 监控断线率：上线后持续统计断线率、重连成功率、恢复耗时，异常波动告警，运维口径见 小程序运维与数据监控教程。
- 准备轮询降级：连接服务异常时自动回落到短轮询或明确提示功能暂不可用，不让页面假死。
保活限制要提前对产品讲清：小程序切后台后连接会被系统挂起或断开，不要承诺「退到后台也能实时收消息」，回前台后的重连与补拉才是正解。前台异常的采集与上报口径见 小程序异常监控与上报教程。
四、避坑清单
这三条坑都和「想当然」有关：硬上长连接、明文传数据、不管后台生命周期。
- 别把请求硬改成 Socket：没有服务端推送需求的业务上长连接，只增加断线、耗电、成本三个负担。
- 别让重连无退避：立即重试的连接风暴会拖垮服务端，指数退避加上限是标配。
- 别明文传敏感数据：走 wss 加密通道，设备控制指令与凭证类数据严禁明文裸传。
- 别假装后台保活：平台对后台长连接有明确限制，产品承诺前先按平台口径确认。
五、常见问题 FAQ
Socket 能替代普通请求吗？
多数情况不必。请求简单、天然幂等、好排查；长连接适合服务端主动推送场景，用错了场景只会增加复杂度和故障面。
和云开发的通道怎么选？
边界写清：云开发的实时数据推送满足需求就优先用，自建 Socket 服务要自己承担连接管理、扩容与监控，成本评估后再定。
小程序切后台连接还在吗？
受限。切后台后系统会挂起脚本并可能断开连接，回前台后应走重连加差量补拉流程，产品上不要承诺后台持续实时。
这个和 GEO 地理位置配置有关系吗？
没有。GEO 指小程序 GEO 地理位置配置——门店地址、经纬度、服务类目，决定附近检索展示，与按城市堆关键词的地域 SEO 无关；Socket 长连接是通信层工程，两者互不影响。
心跳间隔怎么定最合理？
先查服务端代理的空闲超时（如 Nginx 常见 60 秒），心跳间隔取其一半左右并留余量，太短耗电耗流量，太长会被服务端先断开。
