gorilla/websocket需动态设置readdeadline（建议30s，覆盖心跳间隔）和writedeadline（建议10s），每次readmessage前重设；ping响应单独设5s超时，不可复用写超时。
读写超时不能只设一个值，必须按通信阶段拆开配：握手、读、写、心跳响应，各自独立生效。
gorilla/websocket 的 ReadDeadline 和 WriteDeadline 怎么设
gorilla/websocket 不靠全局配置，而是每次 I/O 前调用 SetReadDeadline 或 SetWriteDeadline 动态设置。不调用就无超时，不是“默认 30 秒”。
- 读超时建议设为
30 * time.Second，覆盖典型心跳间隔（如后端每 25 秒发一次 ping） - 写超时建议更短，
10 * time.Second足够，避免大消息阻塞连接 - 每次
conn.ReadMessage()前必须重设SetReadDeadline，否则第一次超时后后续读永远失败 - 发送控制帧（如
WriteControl(websocket.PingMessage, ...)）要单独用time.Now().Add(5*time.Second)控制，不能复用普通写超时
Nginx 反向代理下 proxy_read_timeout 为什么总断连
proxy_read_timeout 只管 Nginx 到后端服务的 TCP 连接“空闲多久没收到数据”，和浏览器到 Nginx 的连接无关。设错就白配。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 它必须 ≥ 后端心跳间隔 × 2，比如后端每 30 秒发一次 ping，这里至少填
90 - 单改它没用：
proxy_send_timeout必须同步设为相同值，否则大消息回传途中被切 - upstream 必须启用
keepalive 32，否则每次心跳都重建 TCP 连接，触发系统级tcp_keepalive_time干预 - Kubernetes Ingress 中要用 annotation：
nginx.ingress.kubernetes.io/proxy-read-timeout: "90"，别去改 ConfigMap 全局配置
uWebSockets 的 idleTimeout 和 sendPingsAutomatically 怎么配合
uWebSockets 的 idleTimeout 是总空闲上限，但实际断连时机由 sendPingsAutomatically 触发的子周期决定——它会自动把总时间拆成“ping 间隔 + margin 容忍窗口”。
- 设
idleTimeout = 30且sendPingsAutomatically = true，等效于每 26 秒发一次 ping，允许最多 4 秒延迟响应 - 如果关掉
sendPingsAutomatically，idleTimeout就变成纯静默等待，一到时间立刻断，毫无缓冲 -
maxBackpressure要同步设（如1024*1024），否则客户端收不过来时，未发数据堆积导致写超时被误判为连接死亡
真正容易被忽略的是：所有超时参数都依赖时钟精度和网络抖动余量。设成整数秒看似干净，但跨公网时 1 秒误差很常见；建议读超时留出 2–3 秒冗余，写超时宁可略短，靠重试补救，别让单次操作拖垮整个连接生命周期。
