简介面向前端开发者的Websocket自动回复消息服务端工具用于后端接口未完成时快速搭建模拟服务进行接口调试、数据联调与自动化测试尤其适合前后端分离开发场景。压缩包共17个文件大小约3.03MB核心为可直接运行的exe程序配套dll运行库、config与xml配置文件、SQLite数据库及使用说明PDF安装部署简单免去手动搭建服务器的繁琐过程。工具提供可视化界面可创建、编辑和管理多个服务端配置基于接口文档快速填充模拟数据并支持一键启动服务实现消息即时收发与自动回复同时生成错误日志方便定位联调问题。内置SQLite数据库支持数据持久化日志文件可追踪收发消息附带的更新说明和PDF文档能帮助新用户快速上手提升前端开发与测试效率。已有383人学习使用。1. Websocket自动回复消息服务端工具先搞清它解决什么问题做实时链路联调时最让人烦躁的不是服务端挂掉而是客户端把消息推过去之后服务端毫无反应。这个标题描述的就是一个非常具体的工具形态以 WebSocket 为承载的服务端程序接收客户端连入读取消息再按规则把应答自动回复出去。它解决的问题不是服务端主动推送而是请求—响应这一侧的回包最常见的落地场景是接口 Mock、链路联调、压测前的连通性自检以及长连接调试。适合后端、测试和运维在本地快速起一个可控回包的服务端也适合做 WebSocket 测试工具的配套服务。先把消息模型搞清楚代码才不会写成聊天室。2. 自动回复服务端的协议基础与消息模型回什么、何时回、怎么回2.1 WebSocket 帧类型自动回复服务端要处理的 4 种帧WebSocket 的长连接里没有请求行和状态码的说法一切交互都是帧。对自动回复服务端来说最常见的出站与入站都是文本帧但只处理文本帧不行。一个能长期开着做联调的工具服务端至少要把操作码分清楚文本帧负责业务消息二进制帧留给弹幕、游戏协议这类数据控制帧里的 Ping/Pong 负责心跳Close 帧负责体面地断开。这件事在 gorilla/websocket 里以常量组暴露写服务端时直接在读写循环里可见// WebSocket 操作码对应 RFC 6455 的 Opcode 字段 const ( TextMessage 1 // 文本帧自动回复里最常见的入站/出站类型 BinaryMessage 2 // 二进制帧游戏端和流数据的入站类型 CloseMessage 8 // 服务端主动断开前一定要发它 PingMessage 9 // 客户端心跳服务端可自动回 Pong PongMessage 10 // 对端 Ping 的正常应答 )这里有一个容易踩坑的细节调用 ReadMessage 读到 PingMessage 时gorilla/websocket 内部会自动回 Pong并且不让这帧冒泡到业务层。所以业务代码里不要再单独处理 Ping 回 Pong否则一个心跳会收到两份 Pong。这个设计对自动回复工具特别重要因为心跳帧不需要走规则引擎。四种帧的服务端处理策略可以整理成一张表帧类型入站时自动回复服务端的动作出站时的用途TextMessage走规则匹配命中选择回包业务回包的主体BinaryMessage按规则记录或原样回传测试二进制协议PingMessagegorilla 自动回 Pong不进业务逻辑不需要手动发CloseMessage读循环读到后应结束连接主动断开前先发避免 1006注意控制帧的处理标准各语言实现的细节不一致用 gorilla/websocket 时不要手写 Pong 回复。2.2 自动回复 vs 主动推送两种服务端消息模式别混在一起很多人提到 WebSocket 服务端第一反应是服务端向所有用户推送消息那是 Spring 里 SimpMessagingTemplate 或游戏服务端活动公告那种场景。自动回复不是这种模型。自动回复的每一次出站都由一条入站消息触发本质是请求—响应主动推送则是服务端自己定节奏往外写。这两种模式的服务端代码结构完全不同。主动推送要维护一个用户连接表定时遍历写消息自动回复则是读一条、回一条链路串行。写自动回复工具时如果脑子里想的是推送模型很容易把连接管理和消息匹配写复杂。实际上自动回复工具只需要一个规则和一个死循环。对比维度自动回复本工具服务端主动推送触发方客户端发消息服务端定时或事件触发回包关系一入一出可配置延时与入站消息无关连接管理简单计数即可需要保存连接表、按组推送典型场景Mock、联调、链路自检行情推送、公告、游戏活动2.3 让自动回复可配置内容匹配、延迟回包与作用域自动回复服务端和普通 echo 服务收到什么回什么的区别在于规则。常见做法是用一份 JSON 配置把规则外置这样改规则时不用重新编译。一个够用的配置结构长这样{ listen: :8080, reply_rules: [ { match: ^ping$, reply: pong, delay_ms: 0 }, { match: ^time$, reply: ${server_time}, delay_ms: 100 }, { match: ^echo:, reply: ${message}, delay_ms: 0 } ] }字段含义分别是match 是匹配入站消息的正则表达式reply 是回包模板${message} 表示原样回传收到的消息${server_time} 是内置变量delay_ms 模拟慢接口用于测试客户端的读超时和重连逻辑。设计规则时要注意多条规则按顺序匹配第一条命中就返回没有命中的消息默认保持静默不回默认错误更贴近真实服务端的行为。2.4 服务端关键参数读超时、写超时、消息大小与心跳间隔实现之前先确认四个参数它们决定自动回复服务端在各种异常场景下的表现参数gorilla 默认工具场景建议说明ReadDeadline无60s 或按规则延迟上限防止半死连接长期占用WriteDeadline无10s回包写不出去时尽快失败ReadBufferSize40964096 或按业务帧上限超过后握手直接失败PingPeriod无30s由服务端决定服务端也可以主动心跳ReadDeadline 不是读一条消息必须在这时间内完成那么简单。它只给每次 ReadMessage 调用设置超时超时后再次 ReadMessage 会直接返回错误连接基本不可复用。所以自动回复服务端如果允许配置 delay_msReadDeadline 要设得比最大 delay_ms 大否则慢回包规则会把连接活活超时掉。3. 用 gorilla/websocket 实现自动回复消息服务端的最小代码骨架3.1 选型gorilla/websocket 是长连接测试工具最常见的选择自动回复服务端要的是一个协议实现完整、API 足够简单、社区用法多的库。Go 生态里常见的有三个gorilla/websocket、gobwas/ws、nhooyr.io/websocket。三者都能完成收发消息上手难度和社区熟悉度差别很大。库特点适合这个工具的场景gorilla/websocket经典实现示例多gin 项目里最常出现联调工具、内部服务求快求稳gobwas/ws零分配、底层可定制高并发网关但 API 偏底层nhooyr.io/websocket新标准、对 context 友好新项目可选但老问题排查资料少我一般会选 gorilla/websocket不只是资料多而是它的 Upgrader 把升级握手、自动 Pong、Close 帧处理都封装好了自动回复工具的核心逻辑只需要写读循环和规则匹配。这与标题里的工具定位很匹配要的是快速跑起来而不是研究协议实现。3.2 最小编程骨架升级连接、读消息、按规则回消息先实现一个不带配置文件的版本规则硬编码在内存里文件不到 80 行package main import ( log net/http regexp time github.com/gorilla/websocket ) var upgrader websocket.Upgrader{ ReadBufferSize: 1024, WriteBufferSize: 1024, // 作为本地联调工具放开跨域校验即可 CheckOrigin: func(r *http.Request) bool { return true }, } type Rule struct { Match string json:match Reply string json:reply DelayMs int64 json:delay_ms } func main() { rules : []Rule{ {Match: ^ping$, Reply: pong}, {Match: ^time$, Reply: time.Now().Format(time.RFC3339)}, {Match: ^echo:, Reply: ${message}}, } http.HandleFunc(/ws, func(w http.ResponseWriter, r *http.Request) { conn, err : upgrader.Upgrade(w, r, nil) if err ! nil { log.Printf(upgrade failed: %v, err) return } handleConn(conn, rules) }) log.Fatal(http.ListenAndServe(:8080, nil)) }这一步是把 HTTP 升级成 WebSocket。ReadBufferSize 和 WriteBufferSize 直接决定底层缓冲容量1024 足以支撑绝大多数自动回复消息CheckOrigin 在本地工具场景不校验来源挂到公网时必须改成按域名校验。升级失败时响应会带 HTTP 错误码不会建立一个半残的 WebSocket 连接。接着是自动回复的核心循环func handleConn(conn *websocket.Conn, rules []Rule) { defer conn.Close() for { // 读文本帧或二进制帧ping 帧由库内部自动回 pong _, msg, err : conn.ReadMessage() if err ! nil { // 客户端断开、写超时、对端发 close 都会走到这里 log.Printf(read exit: %v, err) return } reply : matchReply(string(msg), rules) if reply { continue // 没有匹配规则静默等待下一帧 } if err : conn.WriteMessage(websocket.TextMessage, []byte(reply)); err ! nil { log.Printf(write failed: %v, err) return } } } func matchReply(input string, rules []Rule) string { // 顺序匹配第一条命中即返回 for _, rule : range rules { matched, _ : regexp.MatchString(rule.Match, input) if matched { return rule.Reply } } return }实际实现里 ${message} 这个模板变量还要做一次字符串替换用 strings.ReplaceAll 将 rule.Reply 中的 ${message} 换成 input 即可。读写放在同一个 goroutine 的好处是天然避免 gorilla 的并发写问题。3.3 在 gin 里挂载同一个自动回复服务端很多项目的 WebSocket 入口本来就在 gin 里没必要另起端口。把上面的 handleConn 直接挂到 gin 的 handler 里r : gin.Default() r.GET(/ws, func(c *gin.Context) { conn, err : upgrader.Upgrade(c.Writer, c.Request, nil) if err ! nil { return } handleConn(conn, rules) }) r.Run(:8080)唯一要注意的地方gin 的 handler 里不要提前设 Connection/Upgrade 相关的 Header也不要提前读 c.Request.Body这些操作会和 Upgrader 内部的升级流程抢数据。常见报错是websocket: request contains non-header data或者升级后连接被 400 拒绝。3.4 客户端 1006 与服务端关闭姿势断线重连场景下服务端怎么配合客户端日志里最常见的是[websocket] onclose, code: 1006, reason: , reconnect: true。1006 是规范里的 abnormal closure含义是连接在没有收到 Close 帧的情况下被切断。服务端进程被 kill -9、网络断、网关层空闲超时、客户端读超时都会触发 1006。服务端要配合客户端断线重连核心不是如何不触发 1006而是把主动关闭做得体面func gracefulClose(conn *websocket.Conn) { // 先发关闭帧让对端走到正常的 close 流程 _ conn.WriteControl( websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, bye), time.Now().Add(3*time.Second), ) // 发完再关底层连接 _ conn.Close() }WriteControl 的第三个参数是写超时超过 3 秒还在阻塞就直接放弃关闭帧。这样客户端收到 close 帧后会走 onclose 的完整流程断线重连日志也更干净。1006 并不可怕自动回复工具本来就要配合客户端测重连服务端记录好 ReadMessage 的退出原因即可。4. 用 Websocket King 验证自动回复服务端连接、发包与断线排错4.1 用 Websocket King 完成一次自动回复冒烟验证Websocket King 是一个浏览器里的 WebSocket 客户端调试工具对服务端联调最大的价值是免安装、自定义 Header、支持保存多个连接配置。启动第 3 章的代码后按这个顺序做一遍冒烟验证在连接地址栏填 ws://localhost:8080/ws点 Connect连接状态变成 Connected 后在消息输入框发一条 ping右侧应收到 pong时间戳几乎为 0ms再发一条 time应收到当前服务端时间发一条不匹配规则的 xxx应没有任何回包连接仍然保持。最后一步其实在验证规则未命中默认静默的设计。如果这里收到了一个错误提示说明 matchReply 的返回值被当成了默认回包需要回到 3.2 节检查。4.2 用 curl 验证 HTTP 升级握手有些环境的浏览器连不上本地服务这时可以用 curl 只验证握手阶段curl -i --http1.1 \ -H Connection: Upgrade \ -H Upgrade: websocket \ -H Sec-WebSocket-Version: 13 \ -H Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ \ http://localhost:8080/ws返回101 Switching Protocols表示 HTTP Upgrade 成功。curl 不负责后续的数据帧它只能证明路由和握手没问题。如果这里返回 400优先排查 CheckOrigin 是否放行、gin 路由是否挂对、Upgrader 有没有被重复执行。4.3 一个最小 Go 客户端脚本Websocket King 能验证交互但自动回复服务端还经常要和自动化测试一起跑。写一个 30 行的 Go 客户端可以塞进 CI 做连通性检查package main import ( log time github.com/gorilla/websocket ) func main() { // 连接服务器resp 在握手失败时保留 HTTP 状态码 c, resp, err : websocket.DefaultDialer.Dial(ws://localhost:8080/ws, nil) if err ! nil { log.Fatalf(dial failed, resp%v, err%v, resp, err) } defer c.Close() // 发一条自动回复请求 if err : c.WriteMessage(websocket.TextMessage, []byte(ping)); err ! nil { log.Fatalf(write failed: %v, err) } // 3 秒收不到回包就判定失败 c.SetReadDeadline(time.Now().Add(3 * time.Second)) _, msg, err : c.ReadMessage() if err ! nil { log.Fatalf(read failed: %v, err) } log.Printf(reply: %s, msg) }SetReadDeadline 在这里是必须的否则自动回复服务端如果因为配置错误长期不回包客户端会一直挂在 ReadMessage 上。Dial 返回的 resp 在握手失败时能直接看到 HTTP 状态码比看裸错误信息更有效率。4.4 断线重连场景1006 超时与 reconnect 数据的服务端日志判断自动回复服务端配合断线重连测试时客户端日志会反复出现 onclose 与 reconnect: true这时要先判断 1006 是服务端主动断开、还是网络层断开。判断依据是服务端这一侧的 ReadMessage 退出日志客户端现象服务端日志结论onclose 1006立即重连无任何 read exit 日志网关或防火墙层断开的服务端甚至感知不到onclose 1006重连前有延迟read exit: read tcp ... connection reset by peer对端可能是客户端或中间层主动重置先收到关闭帧再 1006read exit: websocket: close 1000 (normal)已走正常 close 流程1006 是客户端后续超时注意最后一行说明1000 之后的客户端日志理论上不应再出现 1006如果出现了多半是客户端把 close 帧和 1006 的日志顺序打反了不是服务端问题。5. 给自动回复服务端工具加连接数控制、写锁与耗时观测5.1 连接数控制与并发写保护第 3.2 节的代码一个连接一个 goroutine没有连接数上限。联调时几十个连接没问题但 Websocket King 这类工具开着多个标签页服务端很快会被连接洪峰打满。常见做法是维护一个带缓冲的 channel 做信号量var sem make(chan struct{}, 100) // 最多 100 个并发连接 func handleConn(conn *websocket.Conn, rules []Rule) { sem - struct{}{} // 占用一个连接槽 defer func() { -sem }() // 结束时释放 // ...原有读循环 }如果后面的规则允许异步回包比如收到 A 后 5 秒再补一条提醒就会有两个 goroutine 同时写一个连接。gorilla/websocket 的 WriteMessage 不是并发安全的需要自己加锁type replyWriter struct { mu sync.Mutex conn *websocket.Conn } func (w *replyWriter) write(msg []byte) error { w.mu.Lock() defer w.mu.Unlock() _ w.conn.SetWriteDeadline(time.Now().Add(3 * time.Second)) return w.conn.WriteMessage(websocket.TextMessage, msg) }即使暂时不用异步回包这个锁也应该预留。慢回包延迟 客户端超时后重连这两个场景叠加时老连接和新连接可能同时处于服务端同一时间窗口回包会被两个逻辑同时发起。5.2 回包耗时与规则命中观测工具服务端最容易忽视的就是可观测性。自动回复服务端的日志不需要很复杂每条回包记四个值就够了规则名、匹配输入、延迟、耗时。实现上在 matchReply 里顺手带回规则名start : time.Now() reply, ruleName : matchReply(string(msg), rules) elapsed : time.Since(start) log.Printf(rule%s input%q delay%dms elapsed%dus, ruleName, msg, rule.DelayMs, elapsed.Microseconds())日志输出格式直接用键值对方便被日志采集系统抓走。不管是用 Websocket King 做人工测试还是 CI 里的自动化检查服务端的实际回包路径都一眼可查。配置规则之外能控制的变量都收在这里。本文还有配套的精品资源点击获取