应使用结构化 JSON 消息协议而非裸字符串，因需明确 type 字段路由、字段固定可扩展、Payload 解耦业务数据，并先解析 type 再动态反序列化，配合超时控制与 Origin 校验保障生产稳定。
为什么不能直接用 conn.WriteMessage(websocket.TextMessage, "hello")
因为字符串字面量不是 []byte，Go 会隐式转换但容易掩盖类型意图；更重要的是，裸字符串无法携带结构化语义——比如你是发「聊天消息」还是「心跳」、「错误通知」或「用户上线」，服务端和客户端都得靠字符串拼接或前缀判断，一出错就全乱。
- 真实项目中，不同消息类型必须有明确字段标识，否则前端无法安全
switch (data.type) - JSON 是最轻量、跨语言、可验证的协议载体，
json.Marshal和json.Unmarshal成本极低，别省这点 CPU - 别为了“简单”把
Content string当万能字段，后期加个timestamp或from_user_id就得改所有地方
Message 结构体怎么设计才不容易翻车
一个稳定的消息协议，核心是「字段固定 + 类型明确 + 可扩展」。别用 map[string]interface{}，它看着灵活，实则让 JSON 解析失败时只报 json: cannot unmarshal object into Go struct，根本不知道哪字段错了。
- 必加
type string `json:"type"`字段，值如"chat"、"ping"、"auth_ack"，这是路由分发的唯一依据 - 所有字段加
json:tag，且避免空格或特殊字符；omitempty慎用——前端可能依赖默认值做 UI 判断 - 时间戳统一用
int64（毫秒时间戳），别传time.Time，序列化格式不一致易出错 - 示例：
type Message struct { Type string `json:"type"` Timestamp int64 `json:"ts"` Payload json.RawMessage `json:"payload"` }——把业务数据塞进Payload，解耦协议层和业务层
ReadMessage 后为什么不直接 json.Unmarshal 全局结构体
因为 WebSocket 连接里混着多种消息类型，如果硬套一个结构体去解，遇到 type: "ping" 却按 ChatMessage 解，就会丢掉字段或 panic。正确做法是先读 type，再动态选结构体。
- 先用最小结构体提取
type：var header struct{ Type string `json:"type"` } if err := json.Unmarshal(message, &header); err != nil { /* 处理解析失败 */ } - 根据
header.Type分支处理：if header.Type == "chat" { var m ChatMsg; json.Unmarshal(message, &m) } - 别在 for 循环里反复
make([]byte, 4096)，复用sync.Pool或直接用conn.ReadJSON（但它内部仍会分配，且错误信息更模糊） - 注意：如果用了
json.RawMessage字段，Unmarshal不会深拷贝，后续修改原字节切片会影响它——要深拷贝就得append([]byte{}, raw...)
生产环境绕不开的三个校验点
本地跑通不等于线上可用。很多协议问题暴露在高并发、弱网、多端共存场景下。
立即学习“go语言免费学习笔记（深入）”；
-
Upgrader.CheckOrigin必须设为校验函数，开发时写return true可以，上线前必须检查r.Header.Get("Origin")白名单，否则任意网页都能连你服务端 - 连接建立后立刻发一条
{"type":"handshake","seq":123}，客户端收到才开始发业务消息——防止握手完成但首包丢失导致“静默卡死” - 对
WriteMessage加超时控制：用conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，否则慢客户端拖垮整个 goroutine
协议越早定死，前后端联调越省力；但定死不等于不能演进——所有新字段加 omitempty，旧客户端忽略即可。真正麻烦的是删字段或改类型，那得等全量升级完才能动。
