websocket实际传输大小受限于浏览器、服务端和代理中最严者：chrome约32mb、firefox约16mb、safari约8mb；tomcat默认8kb；nginx默认1mb，需调优proxy_buffer_size等参数；推荐分片传输而非硬扩单帧。
WebSocket 协议本身没有硬性长度上限，但实际能传多大，取决于浏览器实现、服务端配置、代理层（如 Nginx）三者中最严的那个限制。别指望“协议没限制”就能随便发 100MB —— Chrome 里单帧超过几十 MB 就可能卡死或静默断连，而 Tomcat 默认只允许 8KB 文本消息。
Chrome / Firefox / Safari 对单帧 WebSocket 消息的实际限制
主流浏览器对单条 WebSocket 消息（即一个文本帧或二进制帧）有隐式大小约束，不是靠文档明说，而是由内存分配策略和解析逻辑决定：
- Chrome（含 Edge）：实测单帧稳定上限约
32MB；超64MB容易触发WebSocket is already in CLOSING or CLOSED state或直接卡在onopen后无响应 - Firefox：相对保守，
16MB以上开始出现延迟解析或连接重置 - Safari（iOS/macOS）：最敏感，
8MB起就可能丢帧，尤其在低内存设备上 - 注意：这些值与字符数无关，只看 UTF-8 编码后的字节长度。一个中文字符在 UTF-8 下占 3 字节，别用
str.length判断是否超限
Tomcat / Spring Boot 默认 textBufferSize 是 8KB
Spring Boot 内嵌 Tomcat 的 WebSocket 实现，默认把单条文本消息截断在 8192 字节。这不是 bug，是防止 OOM 的安全兜底。一旦前端发了 10KB 的 JSON，后端收不到完整内容，连接会立刻关闭，前端看到 CLOSE_ABNORMAL。
必须显式调大这两个参数：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
org.apache.tomcat.websocket.textBufferSize：控制 UTF-8 文本帧最大字节数 -
org.apache.tomcat.websocket.binaryBufferSize：控制二进制帧（如 base64 图片）最大字节数 - Spring Boot 项目中，要在
WebSocketConfig的onStartup()里设置，不能写在@Bean方法里 - 推荐值：传输图片或长日志时设为
52428800（50MB），但需同步检查 JVM 堆内存是否够用（至少-Xmx1g）
Nginx 代理默认只允许 1MB 帧大小
即使前后端都放开，Nginx 作为反向代理会先拦下大帧 —— 它的 proxy_buffer_size 默认仅 4k，且不识别 WebSocket 帧结构，会把整帧当 HTTP body 处理。结果就是：前端发 2MB 消息，Nginx 直接返回 413 Request Entity Too Large 或静默截断。
关键配置项（加在 location 块内）：
-
proxy_buffering off;：必须关，否则帧会被缓存拼接，导致延迟甚至乱序 -
proxy_buffer_size 128k;：设为略大于你预期最大帧（比如 5MB 帧就设5120k） -
proxy_buffers 8 128k;：配合上面，避免 buffer 不足 fallback 到磁盘 -
client_max_body_size 50m;：虽然 WebSocket 不走 body，但某些旧版 Nginx 会误判，加上更稳妥
真正要突破“长度限制”，得绕开单帧思维
与其死磕“怎么让一帧更大”，不如接受 WebSocket 帧机制本来就是为流式通信设计的。浏览器不提供分片 API，但你可以自己做：
- 前端发送大文本前，先
JSON.stringify()+new TextEncoder().encode()得到字节流，再按64KB切块，每块加{ "seq": 1, "total": 5, "data": "..." }头 - 服务端收到后暂存未完成的序列，
total齐了再合并解码 —— 这比调大 buffer 更省内存、更可控 - 对文件类数据（如 PDF、视频片段），根本别走 WebSocket：前端用
fetch上传到独立接口，只通过 WebSocket 推送上传成功后的file_id - 特别注意：不要在心跳包里塞业务数据。有些团队把用户状态也塞进 ping 帧，结果心跳超长触发断连 ——
ping帧应严格保持空载或极短（）
最常被忽略的一点：浏览器限制的是“单帧”，不是“单连接”。哪怕你把所有参数都拉到 100MB，只要某次 send() 超过当前浏览器的解析阈值，连接就废。所以压测时别只看服务端日志，一定要抓 Chrome 的 chrome://net-internals/#events 看真实帧级行为。
