如何在Golang中实现基于TCP的实时聊天系统_Golang TCP聊天系统开发实战

P粉602998670

发布时间：2026-02-07 11:51:53

203人浏览过

来源于php中文网

原创

net.Conn 不能直接复用在多个 goroutine 中读写，因其底层读写共享缓冲与状态机，并发调用易导致 io.ErrUnexpectedEOF 或静默丢包；正确做法是读写分离并加锁串行化写操作。

如何在golang中实现基于tcp的实时聊天系统_golang tcp聊天系统开发实战

为什么 `net.Conn` 不能直接复用在多个 goroutine 中读写

很多初学者会把同一个 net.Conn 同时交给两个 goroutine：一个负责 Read，一个负责 Write。这看似合理，但 TCP 连接本身不是线程安全的——Read 和 Write 共享底层缓冲与状态机，一旦并发调用，可能触发 io.ErrUnexpectedEOF 或静默丢包。

正确做法是：每个连接启动两个明确分工的 goroutine，且用互斥控制写操作（读可独立，写需排队）：

// 示例：写入前加锁
var mu sync.Mutex
go func() {
    scanner := bufio.NewScanner(conn)
    for scanner.Scan() {
        msg := scanner.Text()
        mu.Lock()
        conn.Write([]byte("echo: " + msg + "\n"))
        mu.Unlock()
    }
}()

读 goroutine 可以无锁运行，但别让它阻塞在 Read 上太久；建议用 SetReadDeadline 防僵死
写操作必须串行化，否则可能错乱或 panic；用 sync.Mutex 最轻量，chan []byte 更适合高吞吐场景
不要在 handler 里直接 conn.Close()，应通知读/写 goroutine 自行退出，再统一关闭

如何避免客户端断连后服务器 goroutine 泄漏

常见错误是只监听 conn.Read 返回 io.EOF 就结束，却没处理网络中断、超时、RST 等情况，导致 goroutine 卡在 Read 或 Write 上不退出。

关键要结合连接生命周期管理：

立即学习“go语言免费学习笔记（深入）”；

conn.SetReadDeadline(time.Now().Add(30 * time.Second))
n, err := conn.Read(buf)
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
    // 主动断开闲置连接
    conn.Close()
    return
}
if err == io.EOF || strings.Contains(err.Error(), "broken pipe") {
    conn.Close()
    return
}

每次读/写前都调用 SetReadDeadline / SetWriteDeadline，值随业务逻辑动态更新（比如心跳间隔）
检查 err 时不能只判 io.EOF，还要覆盖 "use of closed network connection"、"broken pipe"、"connection reset by peer"
为每个连接配一个 context.WithCancel，当检测到异常时调用 cancel()，让所有关联 goroutine 快速退出

怎么给每个 TCP 连接分配唯一 ID 并支持广播

Go 没有内置连接 ID，靠 conn.RemoteAddr().String() 不可靠（NAT 后端地址重复），也不能用指针（GC 可能移动）。必须自己生成并维护映射。

Ribbet.ai

免费在线AI图片处理编辑

下载

推荐方案：服务端启动时用 atomic.Int64 递增生成 ID，同时用 sync.Map 存活连接：

var nextID atomic.Int64
var clients sync.Map // map[int64]*client
type client struct {
conn net.Conn
id   int64
}
func newClient(conn net.Conn) *client {
id := nextID.Add(1)
c := &client{conn: conn, id: id}
clients.Store(id, c)
return c
}

广播时遍历 clients.Range，对每个 *client 尝试写入，遇到错误立即 clients.Delete(id) 并关闭 conn
不要在广播循环里做耗时操作（如 JSON 序列化），先序列化好再发，或提前缓存格式化后的字节
客户端重连时，旧 ID 要主动清理；可在新连接握手阶段发送 token，服务端比对并踢掉旧连接

为什么不用 `bufio.Scanner` 做粘包处理

bufio.Scanner 默认按行切割，但聊天消息未必换行；更严重的是它内部有 64KB 缓冲上限，超长消息直接报 scanner: token too long，且无法自定义分隔符长度。

真实场景中必须自己处理粘包，最简方式是「定长头 + 变长体」：

// 发送端：先写 4 字节长度，再写字节流
length := uint32(len(msg))
binary.Write(conn, binary.BigEndian, length)
conn.Write([]byte(msg))
// 接收端：先读 4 字节，再读指定长度
var length uint32
binary.Read(conn, binary.BigEndian, &length)
buf := make([]byte, length)
io.ReadFull(conn, buf) // 阻塞直到读满