Go语言如何写聊天服务器_Go语言即时聊天服务教程【必看】-Golang-PHP中文网

优先用 gorilla/websocket 而非 net/http 或裸 net 包：它封装 websocket 握手与帧处理，避免手动解析 sec-websocket-key；广播需为每个连接配独立写 goroutine 和带缓冲 channel（建议 16–64），防止单连接阻塞全局消息。

go语言如何写聊天服务器_go语言即时聊天服务教程【必看】

用 `net/http` 还是 `net` 包直接写 TCP 服务？

聊天服务器的核心是实时双向通信，HTTP 协议天然不支持服务端主动推消息（除非用长轮询或 SSE，但延迟和连接开销大），所以别用 net/http 搭骨架。直接上 net 包监听 TCP，或者更稳妥地选 gorilla/websocket——它封装了 WebSocket 握手、帧解析和并发安全的读写，比裸写 TCP 少踩 80% 的坑。

常见错误现象：read: connection reset by peer 频繁出现，往往是没处理好连接生命周期，比如 goroutine 泄漏或未关闭底层 conn；用 http.ServeMux 路由 WebSocket 升级请求却忘了调用 Upgrade 方法，结果返回 200 HTML 页面而不是 101 切换协议。

WebSocket 场景优先用 gorilla/websocket，别自己解析 Sec-WebSocket-Key
纯内网低延迟场景（如游戏内聊）可考虑 net + 自定义二进制协议，但得自己实现心跳、粘包、断线重连
net/http.Server 的 ReadTimeout/WriteTimeout 对 WebSocket 无效，必须用 websocket.Upgrader 的 CheckOrigin 和连接级别的 SetReadDeadline

怎么安全地广播消息给所有在线用户？

“遍历 map[*websocket.Conn]struct{} 然后 WriteMessage” 是最常见写法，也是最危险的——任意一个连接卡住（比如客户端网络抖动），整个广播就阻塞，其他用户消息全积压。

正确做法是给每个连接配独立的写 goroutine + 带缓冲的 channel。连接结构体里放 send chan []byte，主循环从 channel 读数据并 WriteMessage；广播时只往所有 channel 发送，不等写完成。

channel 缓冲区大小建议设为 16–64，太小容易丢消息，太大内存占用不可控
必须在 defer 或 close 前关掉 send channel，否则 goroutine 永远阻塞在 ch
不要用全局锁保护用户 map，改用 sync.Map，否则高并发下 Range 和 LoadOrStore 争抢严重

`websocket.Upgrader` 的 `CheckOrigin` 必须自定义吗？

默认情况下，Upgrader.CheckOrigin 返回 false（拒绝所有跨域请求），本地开发时浏览器直接报 Unexpected response code: 403。不改它，前端连握手都过不去。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

线上环境不能简单返回 true，那等于开放任意域名劫持。实际只需校验 r.Header.Get("Origin") 是否在白名单里，比如允许 https://admin.example.com 和 http://localhost:3000。

开发阶段可临时设为 func(r *http.Request) bool { return true }，但提交前务必删掉
如果用 Nginx 反向代理，注意它可能不透传 Origin 头，需加 proxy_set_header Origin $scheme://$host;
CheckOrigin 函数里别做耗时操作（如查 DB），它在每次握手时同步执行，会拖慢连接建立

为什么客户端收不到消息，但服务端没报错？

最常被忽略的是：WebSocket 连接空闲时，NAT 网关或中间代理会静默断开 TCP 连接，而 Go 代码感知不到——ReadMessage 不报错，只是永远阻塞；WriteMessage 也成功返回，其实数据发到了已关闭的 socket 上。

解决办法只有两个：服务端定期发 ping 帧（conn.SetPingHandler + conn.WriteMessage(websocket.PingMessage, nil)），客户端必须响应 pong；同时设好读写超时，超时后主动 Close 连接。

conn.SetReadDeadline(time.Now().Add(30 * time.Second)) 必须在每次 ReadMessage 前调用，不是只设一次
ping 间隔建议 25 秒，比超时短 5 秒，留出网络抖动余量
别依赖 http.ErrAbortHandler 或 io.EOF 判断断连——它们只在连接真正关闭时触发，中间断连完全静默

复杂点在于：ping/pong 本身不携带业务数据，你得在应用层再设计一套心跳确认机制，否则无法区分“连接活着但客户端卡死”和“连接真断了”。这个边界，得靠客户端上报状态+服务端超时清理双保险。