HTML表单提交不能直接触发WebSocket通信，需拦截submit事件、阻止默认行为、手动取值并调用websocket.send()；须确保连接就绪、数据JSON序列化、校验readyState、约定消息格式、处理粘包及优雅关闭。
HTML表单不能直接用 submit 触发 WebSocket 发送
浏览器原生表单的 submit 事件默认走 HTTP（GET 或 POST），和 WebSocket 是两条互不兼容的通道。想“用表单提交 WebSocket”，本质是拦截表单行为，手动取值、构造消息、调用 websocket.send()。
常见错误现象：
– 表单一提交页面就刷新或跳转；
– 控制台报错 WebSocket is already in CLOSING or CLOSED state；
– 表单数据发出去了，但后端收不到或格式错乱（比如没 JSON 序列化）。
- 必须在
form.addEventListener('submit', e => { e.preventDefault(); ... })中阻止默认行为 - 表单字段建议加
name属性，方便用new FormData(form)统一提取 - WebSocket 连接必须已建立（
readyState === 1），否则send()会静默失败 - 发送前务必
JSON.stringify()，后端通常按 JSON 解析，裸对象或 URLSearchParams 格式大概率出错
onmessage 收到响应后，别直接更新 DOM 而忽略连接状态
WebSocket 是长连接，但不保证稳定：网络抖动、服务端重启、心跳超时都会让连接断开。如果只监听 onmessage 并盲目更新页面，可能把旧连接的残留响应刷到新数据上，或在断连后继续尝试渲染空/错数据。
- 每次处理
onmessage前，先检查websocket.readyState === 1 - 服务端返回的数据结构要约定清楚，比如统一带
type字段（"form_submit_ack"/"error"），前端按 type 分支处理，而不是硬写死字段名 - 避免在
onmessage里直接操作document.getElementById—— 如果表单已卸载（比如用户切走了），DOM 元素可能不存在，导致脚本中断
关闭页面前没调用 websocket.close()，容易堆积僵尸连接
用户关掉标签页，WebSocket 不会自动优雅关闭。服务端可能长时间保留这个连接，直到超时踢出，期间占用资源，还可能干扰重连逻辑（比如误判为重复登录）。
从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。
立即学习“前端免费学习笔记（深入）”；
- 必须监听
beforeunload或pagehide，主动调用websocket.close(1000, "user leave") - 不要在
onclose回调里再调一次close()—— 会触发InvalidStateError - 如果业务允许离线缓存提交，需要额外实现本地队列 + 重发机制，这已超出表单+WebSocket 的基础链路
后端没做消息边界处理，前端发多条会粘包或截断
WebSocket 传输的是字节流，不是消息包。前端连续调用两次 send(JSON.stringify(a)) 和 send(JSON.stringify(b))，后端 TCP 层可能合并成一次接收，也可能拆成两段——除非你显式分隔（如换行符）或加长度头，否则无法靠 onmessage 次数对齐业务语义。
- 最简方案：前后端约定每条消息以
\n结尾，后端按行解析；前端发送时补上+\n - 更稳妥方案：前端发之前加长度前缀（如 4 字节大端整数），后端按长度读取；但这要求双方协议一致，调试成本高
- 开发期可用
console.log(event.data)看原始内容，确认是否被截断或拼接——这是定位粘包的第一步
真正麻烦的从来不是“怎么发”，而是“怎么确定对方完整收到了、且按预期解析了”。协议对齐、状态同步、异常兜底，这些没法靠一个 send() 调用解决。
