Golang聊天机器人核心是HTTP入口、WebSocket升级、消息路由与自动回复四步流水线;需用hub统一管理连接、限速防刷、日志记录及超时控制,避免并发写map和重复响应头错误。
用 Golang 开发简易聊天机器人,关键不在“连上 WebSocket”,而在于把 HTTP 入口、WebSocket 升级、消息路由和自动回复这四步串成一条不卡壳的流水线。它不是玩具,而是能立刻跑在本地或内网、响应毫秒级、日志可查、限速防刷的真实小服务。
http: response.WriteHeader called multiple times
这是新手最常 panic 的地方:升级失败后还试图写错误页,或升级成功后又调用 w.Write()。gorilla/websocket 的 Upgrade() 内部已完整处理状态码和响应头,任何额外写操作都会触发该错误。
upgrader.Upgrade() 必须是 handler 中对 http.ResponseWriter 的唯一写操作return,不要调用 http.Error() 或 w.WriteHeader()
w 和 r 失效,后续通信全部走返回的 *websocket.Conn
CheckOrigin: func(r *http.Request) bool { return true };上线前必须收紧,比如只允许 strings.HasSuffix(r.Host, ".yourdomain.com")
func wsHandler(w http.ResponseWriter, r *http.Request) {
conn, err := upgrader.Upgrade(w, r, nil)
if err != nil {
return // 不要 log.Fatal,不要 http.Error
}
defer conn.Close()
// 后续所有读写都走 conn.ReadMessage() / conn.WriteMessage()
}
为什么不能用 map[*websocket.Conn]bool 直接存客户端,而要用 register/unregister channel
Go 的 map 本身不支持并发读写。多个 goroutine 同时增删(比如两个用户几乎同时断开),会直接 panic:fatal error: concurrent map writes。这不是“偶尔出错”,而是必然崩溃。
hub 结构体,含 clients map[*websocket.Conn]bool、register chan *websocket.Conn、unregister chan *websocket.Con
n 和 broadcast chan []byte
hub.run() goroutine,用 select 监听三类 channel 事件,统一增删、广播unregister 发信号——不能只靠 defer conn.Close(),否则 map 里残留脏数据自动回复逻辑必须轻量、同步、无 IO。别在这里调大模型 API 或发 HTTP 请求——那会把整个广播队列拖慢,导致消息堆积、连接超时、用户掉线。
readPump)收到 msg 后,立即调用本地函数如 autoReply(msg),返回字符串strings.HasPrefix()(如 /time)、strings.Contains()(如 “几点”、“时间”),避免正则启动开销conn.WriteMessage(),而是发进全局 broadcast channel ——由 hub 统一推送给所有在线连接send chan []byte,write goroutine 从该 channel 取消息再写,这样单个慢连接不会卡住全体func autoReply(msg string) string {
switch {
case strings.HasPrefix(msg, "/time"):
return time.Now().Format("15:04:05")
case strings.Contains(msg, "你好") || strings.Contains(msg, "hi"):
return "你好!我是小助,可以查时间、记备忘、讲冷笑话~"
default:
return "没听懂,试试说「/time」或「你好」?"
}
}没有这些,它只是个 Demo;加上后,才能扔进测试环境甚至内网小群用几天不翻车。
rateLimiter chan struct{},容量为 3,每秒 time.Tick(1 * time.Second) 往里塞一个 token;发送前先 ,满则丢弃或返回提示
log.Printf("[auto] %s → %s", cleanUsername(user), reply),cleanUsername 建议从消息 JSON 中提取 from 字段,避免空指针/quit,服务端主动调用 conn.Close(),并确保该连接从 hub 的 clients 中被移除,避免 broadcast 时 panicconn.SetReadDeadline(time.Now().Add(30 * time.Second)),防止僵死连接长期占资源最容易被忽略的是:自动回复函数不能有 panic,必须包一层 recover;广播时某个连接 WriteMessage() 失败,必须删 client、关 send channel,否则内存泄漏+ goroutine 泄漏会悄无声息地吃光服务器资源。