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

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

为什么 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 可能移动）。必须自己生成并维护映射。

推荐方案：服务端启动时用 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) // 阻塞直到读满

• 别用 ReadString('n')，换行符可被用户输入，不可信
• io.ReadFull 比反复 Read 更稳，它保证读够字节数或返回错误
• 如果想兼容 websocket 或后续升级，协议头里加个 magic number 和版本字段，方便未来扩展

实际跑起来后，最常被忽略的是连接数突增时的文件描述符耗尽问题。linux 默认单进程最多打开 1024 个 fd，而每个 TCP 连接占一个。上线前务必 ulimit -n 65536，并在代码里用 net.ListenConfig{LimitListener: ...} 做软限流。