websocket连接建立后收不到ai流式响应，根本原因是http.responsewriter被handler返回时自动关闭，必须用gorilla/websocket升级连接，并在同goroutine中持续读取模型流、逐chunk写入；需禁用默认写超时、绑定context生命周期、校验连接状态后再writemessage，并用binarymessage或结构化json确保消息边界。
WebSocket连接建立后收不到AI流式响应？检查 http.ResponseWriter 是否被提前关闭
Go 的 http.Handler 默认在 handler 函数返回时自动关闭连接，而流式生成必须保持连接打开。常见错误是直接在 handler 里调用大模型 SDK 的流式接口，但没做任何连接维持操作，导致客户端只收到空响应或 500 错误。
正确做法是：用 gorilla/websocket 显式升级连接，并在同一个 goroutine 中持续读取模型输出流、逐 chunk 写入 WebSocket 连接：
- 别用
http.ServeHTTP或普通 JSON 响应，必须调用upgrader.Upgrade() - 升级后立即禁用默认超时：
conn.SetWriteDeadline(time.Time{})（否则默认 30s 写超时会断连） - 模型流式输出（如 OpenAI 的
stream: true）需逐行解析data: {...}，不能整块io.Copy
如何安全地把 LLM 的 io.ReadCloser 流转发给 WebSocket？避免 goroutine 泄漏
多数 Go 封装的 LLM 客户端（如 go-openai）返回 io.ReadCloser，直接在主线程里循环读取会阻塞 WebSocket 写入；开新 goroutine 又容易因连接关闭后未清理导致泄漏。
关键控制点在于：用 context.WithCancel 绑定 WebSocket 生命周期，且所有 I/O 操作都带 context：
- 创建 conn 后立刻派生子 context：
ctx, cancel := context.WithCancel(r.Context()) - 读取模型流时用
io.CopyN+ctx.Done()检查，而非无限for { ... } - defer
cancel()，并在conn.Close()后显式调用一次cancel() - 务必用
conn.SetReadLimit(512 * 1024)防止恶意大帧导致 OOM
websocket.WriteMessage() 报错 “use of closed network connection” 怎么定位？
这个错误不一定是客户端断开，更可能是服务端 goroutine 在写入前没检查连接状态。WebSocket 连接可能因心跳超时、代理中断、客户端刷新页面等任意时刻静默关闭。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
必须在每次 WriteMessage() 前加状态校验和重试逻辑：
- 用
conn.PingHandler()和conn.SetPongHandler()实现双向心跳（建议 25s 间隔） - 写入前先调
conn.WriteControl()发个 ping，若失败则跳出循环 - 捕获
websocket.ErrCloseSent和net.ErrClosed，不要忽略它们 - 避免在
WriteMessage()后立即调conn.Close()—— 应改用conn.WriteMessage(websocket.CloseMessage, ...)主动关闭
为什么前端收到文本是乱序或粘包？关键在 websocket.TextMessage 的分帧边界
WebSocket 协议本身不保证消息原子性，LLM 流式输出的每个 token 若单独发 TextMessage，在弱网下会被合并或拆分，前端 onmessage 收到的不是完整 JSON 字段，而是半截字符串。
解决方案不是攒整段再发，而是用结构化协议封装：
- 服务端统一用
websocket.BinaryMessage发送msgpack或自定义二进制帧（含 length header + payload） - 或者强制每条消息为合法 JSON 对象，前端用
JSON.parse()包一层 try/catch，丢弃解析失败的碎片 - 绝对不要在消息体里拼接换行符做分隔 ——
data: {...}\n\n是 SSE 规范，WebSocket 不识别 - 测试时用
wscat -c ws://localhost:8080直连验证原始帧是否符合预期
流式生成最棘手的从来不是模型调用，而是连接状态与数据边界的精确控制。哪怕只漏掉一次 conn.SetReadDeadline() 或少处理一个 context.Canceled，都会让长连接在凌晨三点静默崩塌。
