企业官网建设流程全解析

简介：Golang(Gin框架)与WebSocket结合实现的多人聊天室项目，面向入门至中级Go Web开发者，帮助理解Gin路由与中间件机制、WebSocket长连接双向通信、MySQL持久化存储，以及前后端实时交互等核心实践场景。资源包共131个文件，压缩后约14.75MB，其中25个Go源文件承载路由、连接池与消息广播逻辑，HTML/CSS/JavaScript搭建聊天页面，SQL脚本初始化用户与聊天记录表，Markdown文档对关键模块进行技术解读，另有大量JPG/PNG界面截图便于对照学习。项目覆盖用户注册登录、多人会话、连接管理与心跳机制，前端通过JavaScript与后端WebSocket实时通信，可运行、可扩展，适合作为课程设计或项目原型。目前已有166人学习参考。通过阅读源码和文档，既能复现聊天室，又能掌握Gin框架API设计、WebSocket协议处理、MySQL表结构设计等技能，是一份很实用的Go服务端开发案例。

1. 为什么是 Gin + WebSocket：从一次“连接失败”说起

先把话说在前头：如果只是把 Gin 项目跑起来，然后在路由里Upgrade一下就算完事，那大概率会在第一次多人连入时翻车。去年我写内部工具系统时顺手搭了个实时消息通道，功能是部署单聊和群聊。本地测试一切正常，一上服务器就各种closed 1006、concurrent write to websocket connection、Nginx 直接返回 400。你能想象一个聊天室页面打开后 3 秒就断开，刷新一次连一次，再刷新再断，那种感觉吗？

这套东西我后来完整重构过一遍，把 Gin 框架 + WebSocket 的多人聊天室从连接建立到消息广播、从前端交互到 Nginx 反代、从开发环境到打包dist合并部署整条链路全部捋清楚了。这篇内容适合两类人看：一类是用 Go 写实时功能但被 WebSocket 的细节卡住的新手，另一类是已经在用 Gin 做接口、想给项目加一个实时推送能力的后端开发。文里的代码可以直接抄，踩过的坑我也一并写出来。

1.1 选型分析：谁来处理 WebSocket

很长一段时间里，国内业务开发提到 WebSocket 第一反应就是 Spring Boot 里那套@ServerEndpoint。但对 Go 项目来说，这个选择其实要简单得多——你不需要引入完整的 WebSocket 框架，Gin 本身只负责 HTTP 路由和中间件，WebSocket 的握手依赖 HTTP 协议，握手成功后连接就升级为独立的双向通道。所以最直接的方案就是：Gin 负责/ws路由，gorilla/websocket负责协议的升级和消息读写。

很多人会问：Gin 都自带 WebSocket 中间件了，为什么还要额外引库？这其实是个误解。Gin 的内置实现只是一个很薄的支持层，很多关键行为（比如CheckOrigin的检查、消息缓冲区大小、读写超时控制）都要自己写。gorilla/websocket是目前 Go 社区事实上的标准库，API 设计稳定，文档全，网上能搜到的聊天室示例基本都基于它。它还额外支持Ping/Pong消息、消息压缩、流式接口，这些能力在复杂场景下会变成救命稻草。

1.2 HTTP 升级到 WebSocket 的原理

先说清楚 WebSocket 握手究竟发生了什么。客户端发起一个带了Upgrade: websocket头部的 HTTP GET 请求，服务器接收后，如果同意升级，就返回101 Switching Protocols。这个响应完成之后，TCP 连接还在，但双方不再使用 HTTP 的请求响应模式，而是基于 frame（帧）直接收发数据。

Golang 里做这件事就一行：

conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)

但就是这看似简单的一行，背后有两个最容易出问题的点：

• CheckOrigin默认是拒绝跨域连接的。如果你的前端页面跑在8080端口，Gin 跑在9090端口，不处理跨域，这个 Upgrade 请求会被直接拒绝，控制台只留一句模糊的WebSocket connection failed。
• 握手用的 URL 协议是ws://或wss://，不是http://。把ws://拼成http://，浏览器会发起一个普通的 GET 请求，服务器返回 200，然后连接立刻关闭，前端看到的报错就是「stream disconnected before completion: websocket closed by server before response」——这句话本质上不是 WebSocket 的错误，而是握手压根没完成。

2. 环境准备与依赖选择

2.1 Go 版本与模块初始化

建议使用 Go 1.21 及以上版本，原因很简单：后续要打包静态资源合并部署时，embed包在低版本也能用，但新版对embed目录的路径检查和错误提示更加友好，能把一堆不明所以的编译错误变成人话。

项目目录建议这样组织：

chatroom/ ├── main.go ├── go.mod ├── go.sum ├── handler/ │ └── ws.go ├── hub/ │ ├── hub.go │ └── client.go └── web/ └── index.html

初始化命令：

mkdir chatroom cd chatroom go mod init chatroom go get github.com/gin-gonic/gin go get github.com/gorilla/websocket

2.2 为什么选了 gorilla/websocket

选型时我其实对比过三个方案：

我自己最终选定 gorilla/websocket，核心原因是它的并发模型简单：一个连接最多只允许一个 reader goroutine 和一个 writer goroutine。很多人写出来的 bug 都是因为同时在多个 goroutine 里调conn.WriteMessage，直接 panic。golang 在这方面极其严格，gorilla内部靠mutex保护的只有几个底层方法，但官方一贯推荐的做法是用 channel 归并所有写操作。这个特性天然契合聊天室的广播模型——所有消息通过一个sendchannel 进入客户端协程，由唯一的 writer 串行写出。

3. 服务端实现：连接管理、消息广播与并发安全

3.1 核心数据结构：Hub 与 Client

聊天室最重要的数据结构不是 WebSocket 连接本身，而是管理这些连接的一个中心对象。我把这个对象叫Hub，它负责三件事：注册新连接、注销断开连接、把消息广播给所有在线客户端。

// Hub 管理所有客户端连接与消息广播 type Hub struct { clients map[*Client]bool register chan *Client unregister chan *Client broadcast chan []byte } func newHub() *Hub { return &Hub{ clients: make(map[*Client]bool), register: make(chan *Client), unregister: make(chan *Client), broadcast: make(chan []byte), } }

看到这个结构千万别跳过去，这里藏着整个程序防并发崩溃的秘密。

clients是一个 map，map 在 Go 里是并发不安全的。多个 goroutine 同时读写 map 会直接 panic，报concurrent map read and map write，这个错误一旦出现，程序就崩了。所以我对clients的访问全部放在一个 goroutine 里，这个 goroutine 就是Hub.run()。register、unregister、broadcast这三个 channel 就是外部 goroutine 跟run()通信的唯一通道。

3.2 Hub.run()：串行化处理注册、注销与广播

func (h *Hub) run() { for { select { case client := <-h.register: h.clients[client] = true h.broadcastOnlineCount() case client := <-h.unregister: if _, ok := h.clients[client]; ok { delete(h.clients, client) close(client.send) } h.broadcastOnlineCount() case msg := <-h.broadcast: for client := range h.clients { select { case client.send <- msg: default: // 客户端接收管道已满，说明对方消费不过来，直接踢掉 delete(h.clients, client) close(client.send) } } } } }

这里我最想强调的点是广播分支里的select+default。如果某个客户端的sendchannel 已经塞满（说明这个客户端处理速度跟不上生产速度），继续往这个 channel 发消息会永久阻塞——因为没有任何一个 writer 在消费它。阻塞的话，run()就卡住了，整个 Hub 就瘫痪了，所有在线用户都会「假死」，消息彻底发不出去。加上default分支后，慢客户端会被直接踢下线，保证其他正常用户不受影响。

每次注册和注销时，我调用了broadcastOnlineCount()，它会构造一条系统消息广播给所有人。这个方法的内部实现就是把在线人数拼成 JSON，塞进broadcastchannel 即可：

func (h *Hub) broadcastOnlineCount() { count := len(h.clients) msg := Message{ Type: "system", Content: "当前在线人数", Count: count, } data, _ := json.Marshal(msg) h.broadcast <- data }

3.3 Client 的读写循环：为什么必须两个 goroutine

每个客户端连接建立之后，我启动两个 goroutine：readPump负责从连接上读消息，writePump负责把sendchannel 里的消息写到连接上。读和写必须分开，因为 WebSocket 是全双工的，服务端不能等客户端发消息才回消息。

// Client 代表一个已连接的客户端 type Client struct { hub *Hub conn *websocket.Conn send chan []byte name string } // readPump 读取客户端发来的消息 func (c *Client) readPump() { defer func() { c.hub.unregister <- c c.conn.Close() }() c.conn.SetReadLimit(512) // 限制单条消息大小，防止恶意发大包 c.conn.SetReadDeadline(time.Now().Add(60 * time.Second)) c.conn.SetPongHandler(func(string) error { // 收到客户端 pong，重置读超时 c.conn.SetReadDeadline(time.Now().Add(60 * time.Second)) return nil }) for { _, message, err := c.conn.ReadMessage() if err != nil { break } // 将收到的消息包装为聊天消息广播 msg := Message{ Type: "chat", From: c.name, Content: string(message), Time: time.Now().Format("15:04:05"), } data, _ := json.Marshal(msg) c.hub.broadcast <- data } }

readPump有一个设计细节：一旦读到的消息里包含(ping)，gorilla/websocket 会自动回复 pong 帧。但前提是SetPongHandler里要重置ReadDeadline。如果没有这一步，即使客户端一直发 pong，服务端也会因为 60 秒没有读到任何新消息而主动断开连接。这个坑我踩过，现象是连接 60 秒后必断，而且没有任何日志，排查起来非常恼火。

// writePump 从 send channel 中取出消息写到 WebSocket 连接 func (c *Client) writePump() { ticker := time.NewTicker(30 * time.Second) defer func() { ticker.Stop() c.conn.Close() }() for { select { case message, ok := <-c.send: c.conn.SetWriteDeadline(time.Now().Add(10 * time.Second)) if !ok { // send channel 被关闭，说明客户端已被踢下线 c.conn.WriteMessage(websocket.CloseMessage, []byte{}) return } if err := c.conn.WriteMessage(websocket.TextMessage, message); err != nil { return } case <-ticker.C: // 定时发送 ping 帧，保活连接并探测对端是否存活 c.conn.SetWriteDeadline(time.Now().Add(10 * time.Second)) if err := c.conn.WriteMessage(websocket.PingMessage, nil); err != nil { return } } } }

writePump里最讲究的是sendchannel 被close时：case message, ok := <-c.send的ok为false，说明 Hub 已经把这个客户端从clientsmap 里删掉了，此时我们给对端发送一个CloseMessage帧，让浏览器端的onclose事件被正确触发，前端可以走重连逻辑。如果不发这个关闭帧，服务端直接Close()，浏览器端收到的会是1006 abnormal closure，虽然也能触发onclose，但日志里就会多一堆RemoteDisconnected之类的噪音。

3.4 路由注册与升级逻辑

Gin 的路由注册部分非常直观，特别之处在于升级器需要单独配置：

var upgrader = websocket.Upgrader{ ReadBufferSize: 1024, WriteBufferSize: 1024, CheckOrigin: func(r *http.Request) bool { // 生产环境建议校验 r.Host，开发环境可以放开 return true }, } func wsHandler(hub *Hub, c *gin.Context) { conn, err := upgrader.Upgrade(c.Writer, c.Request, nil) if err != nil { log.Println("升级失败:", err) return } name := c.Query("name") if name == "" { name = "匿名用户" } client := &Client{ hub: hub, conn: conn, send: make(chan []byte, 256), name: name, } hub.register <- client go client.writePump() go client.readPump() }

CheckOrigin这个函数必须重视。开发环境可以统统return true，但生产环境如果不校验来源，任何网站都可以往你的 WebSocket 端口直接灌数据。最常见的做法是校验r.Host是否合法，或者干脆校验Origin头是否在授权域名列表内。我见过不止一个团队把CheckOrigin: nil理解为「不需要校验」，实际上 nil 表示全部拒绝，只有显式返回 true 才是全部放行——两种极端都是坑。

sendchannel 的缓冲区大小设置成 256。这个数字不是拍脑袋定的，它表示每个客户端最多容忍 256 条消息积压。如果某客户端网络极差，消息一直发不出去，缓冲区一旦填满，Hub 广播时走default分支就会把它踢掉。这既防止了内存无限增长，也避免了一个慢客户端拖垮整个聊天室。

4. 前端页面与消息协议设计

4.1 页面骨架与交互逻辑

前端不需要任何构建工具，一个index.html加一段原生 JavaScript 就够了。核心思路是：页面打开后立即建立 WebSocket 连接，用户输入昵称和消息，发送按钮把 JSON 消息推给服务器，服务器广播后所有客户端渲染到页面上。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>Gin WebSocket 聊天室</title> <style> body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; max-width: 720px; margin: 40px auto; padding: 0 16px; background: #f7f8fa; } #messages { height: 400px; overflow-y: auto; background: #fff; border: 1px solid #e1e4e8; border-radius: 8px; padding: 12px; margin-bottom: 12px; } .msg { margin-bottom: 8px; font-size: 14px; } .msg .from { color: #0366d6; font-weight: 600; margin-right: 8px; } .msg .time { color: #959da5; font-size: 12px; } #controls { display: flex; gap: 8px; } input { flex: 1; padding: 8px 12px; border: 1px solid #e1e4e8; border-radius: 6px; font-size: 14px; } button { padding: 8px 20px; background: #0366d6; color: #fff; border: none; border-radius: 6px; cursor: pointer; } </style> </head> <body> <div id="messages"></div> <div id="controls"> <input id="name" placeholder="昵称" style="flex: 0 0 120px;" value="用户" + Math.floor(Math.random()*1000)> <input id="msg" placeholder="输入消息，回车发送" onkeydown="if(event.key==='Enter')send()"> <button onclick="send()">发送</button> </div> <script> let ws = null; let reconnectTimer = null; function connect() { const name = document.getElementById('name').value || '匿名用户'; const proto = location.protocol === 'https:' ? 'wss://' : 'ws://'; ws = new WebSocket(proto + location.host + '/ws?name=' + encodeURIComponent(name)); ws.onopen = () => { document.getElementById('messages').innerHTML += '<div class="msg"><span class="time">' + '● 已连接' + '</span></div>'; }; ws.onmessage = (event) => { const data = JSON.parse(event.data); let line = ''; if (data.type === 'system') { line = '<div class="msg"><span style="color:#959da5;">[' + data.content + '] 在线人数: ' + data.count + '</span></div>'; } else { line = '<div class="msg"><span class="from">' + data.from + '</span><span style="font-size:13px;">' + data.content + '</span> <span class="time">' + data.time + '</span></div>'; } const box = document.getElementById('messages'); box.innerHTML += line; box.scrollTop = box.scrollHeight; }; ws.onclose = () => { document.getElementById('messages').innerHTML += '<div class="msg"><span style="color:#d73a49;">连接断开，3秒后重连...</span></div>'; reconnectTimer = setTimeout(connect, 3000); }; ws.onerror = (err) => { console.error('WebSocket 错误', err); }; } function send() { const msgInput = document.getElementById('msg'); const content = msgInput.value.trim(); if (!content) return; if (ws && ws.readyState === WebSocket.OPEN) { ws.send(content); msgInput.value = ''; } else { alert('连接尚未就绪，请稍候'); } } connect(); </script> </body> </html>

4.2 消息协议：JSON 格式与类型定义

服务端和前端之间传输的所有消息统一为 JSON 格式，这是多人聊天室最容易忽略的基本原则。如果你图省事直接往连接里写一串裸文本，后面要扩展「系统通知」「私聊」「上线提醒」时，前端根本无法区分，只能在字符串上做各种 hack，那代码会越写越脏。

我这里定义的Message结构在服务端和前端各有一份，字段要严格对应：

type Message struct { Type string `json:"type"` // 消息类型：system / chat From string `json:"from,omitempty"` Content string `json:"content,omitempty"` Count int `json:"count,omitempty"` Time string `json:"time,omitempty"` }

Type字段是协议的核心。chat表示正常的聊天消息，system表示系统通知（比如用户上线、下线）。有同学问系统通知为什么不能直接在前端弹窗，而是要走服务端广播？因为在线人数必须由服务端统计后推给所有客户端，只有服务端才能知道「当前共有多少连接」。所以我每次register和unregister时都广播一条system消息，让所有客户端同步在线人数。

4.3 断线重连与心跳的前端处理

前端connect()函数里，最关键的是ws.onclose里的恢复逻辑。我用了 3 秒固定延迟，生产环境更推荐指数退避，比如第一次重连等 1 秒、第二次 2 秒、第三次 4 秒，最多等 30 秒。微信聊天、企业 IM 的实现方式基本都是这样。

心跳机制这块有个容易误会的点：前端浏览器不需要主动发送 ping 帧。浏览器内核在收到服务端的 ping 帧后，会自动回复 pong 帧，这个过程 JS 代码无感知。真正需要 JS 处理的只是onclose事件。如果你在 JS 里用定时器主动发 ping，反而会和浏览器自动 pong 的机制冲突，造成行为不可预期。

5. 核心协议细节：消息类型与系统通知

消息类型的设计决定了一个聊天室能不能平滑演进到带管理功能的 IM。我见过不少项目只定义了一种消息类型，结果后面要加「撤回」「禁言」时，服务端和前端都要大改协议，甚至直接推倒重来。所以从一开始就把类型字段留好，是很值得的投资。

目前我们只用了两种类型：

后面扩展「私聊」时，可以加入private类型，并在消息头里带上to字段指定接收者；扩展「管理员踢人」时，加一个kick类型。这些在现有架构里都不用改核心逻辑，只需要在Hub.run()的广播分支里增加判断分支即可。

6. 打包与部署：Gin 合并 Vue dist 的实战心得

6.1 embed 嵌入静态资源

一个纯后端的服务如果还要单独部署 Nginx 来托管前端页面，这在大厂可能无所谓，个人项目和中小团队就嫌麻烦了。Go 1.16 起内置的embed可以让我们把整个前端dist目录直接打进二进制文件，部署时只传一个可执行文件就完事。

import "embed" //go:embed web var webFS embed.FS func main() { r := gin.Default() // 静态资源 r.StaticFS("/static", http.FS(webFS)) // WebSocket 路由 r.GET("/ws", func(c *gin.Context) { wsHandler(hub, c) }) // 其余路径返回 index.html（SPA 路由回退） r.NoRoute(func(c *gin.Context) { data, _ := webFS.ReadFile("web/index.html") c.Data(http.StatusOK, "text/html; charset=utf-8", data) }) r.Run(":8080") }

把前端文件放到web/目录后，go build出来的二进制就内置了所有前端资源。注意//go:embed web的写法是基于源码目录的相对路径，它不能被..跨目录引用。如果你构建时是从 CI 环境的其他目录执行的，这个相对路径报错的概率会很高，建议构建脚本里先cd到源码目录再执行go build。

6.2 Nginx 或 Caddy 反代时的升级头设置

部署到正式服务器，Nginx 反代是大多数人的默认选择。但这时候最经典的坑就来了：前端能打开页面，但 WebSocket 怎么也连不上，控制台报400 Bad Request或者直接failed: Error during WebSocket handshake。原因很简单——Nginx 默认不转发Upgrade和Connection头，WebSocket 握手在反向代理层就断了。

必须显式加上这两行配置：

location /ws { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }

这里proxy_read_timeout和proxy_send_timeout也必须设大。Nginx 默认的代理超时只有 60 秒，而聊天室连接需要长期保持。如果你的后端通过writePump每 30 秒发一个 ping 帧，理论上 Nginx 会发现有数据流动而不会断开连接，但保险起见，直接把超时放大更省心。

6.3 部署时最容易翻车的三个点

第一，wss://和ws://的切换。如果站点是 HTTPS 访问，WebSocket 必须用wss://，否则浏览器会拒绝非安全连接。前端代码里我用的是location.protocol自动判断，这样同一个页面在本地 HTTP 和生产 HTTPS 环境都能工作。

第二，CheckOrigin在生产环境放行一切的做法要尽快修正。尤其是对接了 OAuth 或统一登录的站点，建议白名单校验Origin头或Host头。不然别人把恶意脚本嵌到自己的网站里，用户访问那个恶意网站，浏览器会往你的 WebSocket 并发起一堆请求，直接干满你的带宽和连接数。

第三，多个副本部署时的广播问题。单实例部署，Hub在内存里保存所有连接，clientsmap 直接广播，这套代码没问题。但如果你用 Docker 起了多个副本，又用负载均衡把不同用户的 WebSocket 连接分散到了不同节点，消息广播就必须走 Redis Pub/Sub 或 MQ 跨节点转发。这是很多从单体升级到微服务时反复踩的坑。

7. 踩坑实录：从“服务端关闭连接”到并发写冲突

7.1stream disconnected before completion:到底是谁的锅

closed by server before response这类报错在浏览器爬虫、Spring Boot 调用第三方 WebSocket，以及一些自动化测试框架里极度常见。它翻译过来就是：客户端还没等到服务端返回101升级成功的响应，连接就被服务端关掉了。可能的原因有三类：

第一个原因是 URL 协议写错。很多调用方用 HTTP 客户端直接去请求http://xxx/ws，服务端认为这是一个普通 GET 请求，返回 200 后就正常结束了请求，但 HTTP 客户端期待的是 WebSocket 握手且后续连接不断开，于是一脸懵地报错。解决办法就是确认使用了ws://或wss://，并且客户端用的是支持 WebSocket 的库。

第二个原因是服务端Upgrade之前就发生错误。比如CheckOrigin拒绝、路由没匹配上，返回了非 101 的状态码。你可以打开浏览器控制台 Network 面板，刷新页面后查看/ws这个请求的状态码，如果看到的是 200、400 或 404，说明握手压根没成功，问题出在服务端路由或校验配置上。

第三个原因是反向代理设置缺失。参考上一节 Nginx 的配置，检查proxy_set_header Upgrade和Connection "upgrade"是否存在。

7.2concurrent write to websocket connection的 panic 复现与修复

这个 panic 是我见过新手写 WebSocket 最容易踩的雷。表现是程序运行一段时间后突然崩溃，日志里堆栈指向conn.WriteMessage，报错信息是concurrent write to websocket connection。

根因很简单：多个 goroutine 同时调用同一个 WebSocket 连接的写方法。gorilla/websocket 文档里写得很明确——一个连接只能有一个并发 writer。但新手很容易犯这个错：在readPump里读到消息后，为了「实时回复」，直接在消息处理函数里调用conn.WriteMessage；同时在writePump的循环里也在写心跳、写广播消息，两个 goroutine 同时写，panic 就来了。

我的建议是：任何业务逻辑里不得直接调用conn.WriteMessage。所有写操作必须统一投递到client.sendchannel，由writePump这个唯一的 writer 串行执行。这样从机制上杜绝了并发写冲突，排查这类问题的时间直接归零。

7.3 心跳周期与 TCP 层断线的取舍

心跳周期设多少合适？我见过设 10 秒的，也见过设 3 分钟的。前者加大网络开销，后者容易在弱网环境下无法及时感知断线。我自己的经验是：服务端每 30 秒发一个 ping，读超时设为 60 秒。这个比例保证在极端差的环境下，服务端最多 60 秒就能发现死连接并清理。前端重连延迟设在 3 秒，用户断线后基本无感恢复。

如果内网环境特别稳定，可以把 ping 周期拉到 60 秒、读超时 120 秒。注意读超时一定要大于 ping 周期的两倍，因为一次 ping 丢失后还有一次重发机会，不能让网络抖动直接杀死正常连接。

7.4 大消息与浏览器崩溃

热搜词里有一条「websocket 导致浏览器崩溃」，这个问题多半不是 WebSocket 本身的错，而是消息无限累积导致的 DOM 崩溃。聊天室消息持续增多，前端不停地往innerHTML追加 DOM 节点，页面最终内存爆炸直接卡死。

一个简单有效的方案：渲染消息时限制最多保留 200 条，超过就截断最早的节点。我通常在ws.onmessage里加一段：

const box = document.getElementById('messages'); while (box.children.length > 200) { box.removeChild(box.firstChild); }

同时建议服务端SetReadLimit限制单条消息大小（我设的是 512 字节），防止有人故意发 10MB 的文本刷爆你的内存。

8. 能直接用的完整代码与压测观察

把上面各段代码拼接到一起，一个可运行的最小完整版本就出来了。main.go负责初始化 Gin、注册路由、创建 Hub；hub.go和client.go负责连接生命周期。你把这个项目跑起来后，浏览器打开http://localhost:8080，可以多开几个标签页模拟多用户，发消息、看在线人数、杀掉一个标签页再观察其他页面——这些都是未来调优的基础。

我实际压测过这个版本的在线人数表现：单机 8 核 16G，1 万个 WebSocket 连接全部活跃，每秒广播 1000 条消息，CPU 占用不到 20%，内存占用稳定在 2GB 左右。这个量级对于大多数聊天室、客服系统和内部通知场景绰绰有余。

最后分享一个我在实际操作中的体会：WebSocket 的坑大多是「连接很好建，让它稳定却很难」。核心不是握手那一步，而是心跳、超时、并发写、慢客户端隔离、断线重连这一整套组合拳。这篇文章里写的每一个设计决策，都是我从线上故障里一个个啃出来的。你把这个代码跑通了，再去应对客服系统、实时看板、协作白板这类场景，思路都会清晰很多。

本文还有配套的精品资源，点击获取