go无法连接wss://api.deepseek.com是因deepseek官方截至2026年5月未开放websocket端点，该地址返回404或426错误；所谓“deepseek websocket”实为siliconflow、ollama等第三方兼容代理服务。
Go 连不上 wss://api.deepseek.com 是设计如此，不是你代码写错了
DeepSeek 官方 API（截至 2026 年 5 月）压根没开放 WebSocket 端点。wss://api.deepseek.com 这个地址不存在，任何尝试 Dial 它的操作都会收到 404 或 426 Upgrade Required 但无有效 Upgrade header 的响应。网上流传的“DeepSeek WebSocket 示例”，实际连的全是第三方兼容代理，比如：wss://cloud.siliconflow.cn/v1/chat/completions、wss://api.ollama.ai/v1/chat/completions，或是你本地用 vLLM + OpenAI-compatible API 暴露出来的地址。
Go 用 gorilla/websocket 对接流式 WebSocket，关键在协议对齐
第三方 WSS 服务大多模仿 OpenAI 协议，但细节常有出入。你发过去的消息体必须是标准 JSON，且字段名、嵌套结构、是否需要 model 字段等，都得按目标服务文档来。常见踩坑点：
-
stream字段必须是布尔值true（不是字符串"true"），否则有些代理直接静默忽略流式逻辑 - 部分服务要求
messages数组里每个对象必须含role和content，缺一不可；system角色可能不被支持 - 响应帧可能是文本帧（
websocket.TextMessage）也可能是二进制帧（websocket.BinaryMessage），需先conn.ReadMessage()再判断类型，不能默认只读文本 - 有些代理会在首帧返回完整
choices[0].delta，后续帧才开始流式；有些则首帧就是空或只含id/object，真正内容从第二帧起
双向通信 ≠ 双向“语义”交互，中断和控制要靠额外字段
WebSocket 连接建立后，你可以随时往服务端发新消息，但 DeepSeek 类模型本身不原生支持“中断当前生成”或“动态插入选项”。所谓“双向”，多数只是前端能发 {"type": "stop"} 这类控制指令——前提是代理层实现了该扩展。实操中要注意：
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- 不要假设
close连接就能终止推理：很多代理会忽略连接关闭，继续把剩余 token 推完再关 - 若需实时中断，优先查代理文档是否支持
stop字段（如加在请求体里）或专用控制 endpoint（如POST /v1/chat/cancel） - 客户端发控制消息后，必须主动清空本地 buffer 并暂停渲染，否则可能把已取消的残余 token 当作有效内容展示
- 同一连接上连续发多个问题，必须确保前一个响应已完全结束（收到
done或finish_reason），否则容易触发状态错乱
别绕过 REST 流式去硬上 WebSocket，除非真有强需求
net/http + text/event-stream 是 DeepSeek 官方唯一保证兼容的流式路径。它天然支持 HTTP 代理、自动重试、超时控制，Go 标准库几行代码就能跑通。WebSocket 带来的额外复杂度，只有在以下场景才值得承担：
- 前端运行在旧版 WebView（如 Android 4.x）中，不支持
EventSource - 你已有成熟 WS 消息总线（如基于
gorilla/websocket的内部广播系统），想复用连接池和心跳逻辑 - 需要服务端主动推送非模型响应的数据（如打字状态、工具调用中间结果、token 使用统计）
绝大多数对话场景下，强行用 WebSocket 只会增加连接保活、断线重连、ping/pong 超时处理等负担，而收益微乎其微。官方 SSE 接口的 TTFB 已稳定在 200ms 内，和 WebSocket 的 50ms 差距，在用户感知层面几乎不可分辨。
