websocket发送超大消息断开是因缓冲区或代理限制，需分片处理：chrome frames页查1009错误码确认帧超限；gorilla/websocket用writemessage自动分片并调大writebuffersize；spring boot需同步调大tomcat、nginx及网关配置。
WebSocket 发送超大消息（比如 >64KB 的二进制数据或长 JSON）时，连接直接断开、控制台静默失败、readyState 突然变成 CLOSING——这不是你的代码逻辑错了，而是被底层缓冲区、代理层或服务端配置卡住了。分片不是“可选优化”，而是绕过这些硬限制的必要手段。
Chrome DevTools 里怎么确认是帧大小超限？
别猜，直接看帧。打开 Network 面板 → 筛选 WS → 点击对应连接 → 切到 Frames 标签页：
- 如果发送一条大消息后，Frames 列表里只出现一个
Text或Binary条目，但紧接着就弹出Close帧（状态码如1009），基本就是服务端或中间件拒绝了该帧 -
1009表示Message Too Big，是 RFC 6455 明确定义的错误码，Tomcat、Jetty、Netty、Spring Cloud Gateway 都可能抛这个 - 如果 Frames 里能看到多个连续的
Continuation帧（opcode0x0），说明浏览器已自动分片，问题大概率出在服务端没正确处理 continuation 帧
gorilla/websocket 服务端如何启用并控制分片？
gorilla/websocket 默认对 >2×writeBuf 大小的消息自动分片，但阈值不可配。真正可控的是写入行为本身：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 确保你用的是
conn.WriteMessage()而非conn.Write()：前者走 messageWriter 分片逻辑，后者绕过所有分片机制，直接发原始帧 - 手动控制缓冲区大小：初始化时传入
websocket.Upgrader{WriteBufferSize: 65536}，避免小缓冲区触发频繁 flush 和额外分片开销 - 不要依赖
fragmentOutgoingMessages（这是websocket-node的配置项，gorilla 里不存在）
Spring Boot + Tomcat 场景下，光改 max-text-message-buffer-size 不够
这个配置只管 Tomcat 自身 WebSocket 实现的接收缓冲区，但很多项目实际卡在更外层：
- 若用了 Spring Cloud Gateway，必须同步调大 Netty 的
maxFramePayloadLength，否则在握手阶段就被拦住，日志里是CorruptedFrameException: Max frame length of 65536 has been exceeded - 若用了 Nginx 反代，需加
proxy_buffer_size 128k和proxy_buffers 8 128k，否则默认 4k 缓冲区会截断大帧 -
server.tomcat.max-swallow-size: -1必须设，否则 Tomcat 在连接关闭时会试图读完剩余字节，导致线程阻塞和内存泄漏
前端手动分片时最容易漏掉的三个细节
浏览器自动分片省事但不可控；手动分片能规避中间件差异，但必须自己兜底：
- 不能用
ws.send()直接发多段——HTML5 API 不允许你指定fin和opcode，所有“手动分片”实际都是应用层协议：把大 payload 拆成带seq和total的小 JSON 包，每包独立send() - 必须实现接收端校验：仅靠
onmessage收到完整 JSON 不代表数据正确，网络丢包会导致某块缺失，得靠序号检测 + 超时重发 - 切块大小建议 ≤ 64KB（65536 字节），避开多数网关和 TLS 层的默认帧上限，也利于 Chrome DevTools 中逐帧排查
分片不是贴膏药，而是把“单次大操作”变成“多次小操作”。真正的难点不在拆，而在收全、对齐、校验、超时——这些逻辑一旦漏掉一环，表面看着连上了，数据却在半路悄悄蒸发。
