17370845950

net.Conn不能直接复用在多个goroutine中读写，因其底层读写缓冲区不并发安全；正确做法是读写分离、channel通信，并配合适当超时与连接管理。

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

很多人一上来就用同一个 conn 在两个 goroutine 里分别 conn.Read() 和 conn.Write()，结果发现消息乱序、阻塞、甚至 panic。根本原因是 net.Conn 的底层读写缓冲区不保证并发安全——Read() 和 Write() 都会操作连接的内核 socket 缓冲区，没有内置锁或序列化机制。

正确做法是：一个 goroutine 专责读（处理输入），另一个专责写（发送输出），中间用 channel 通信。例如：

go func() {
    buf := make([]byte, 1024)
    for {
        n, err := conn.Read(buf)
        if err != nil {
            return
        }
        msg := string(buf[:n])
        inputCh <- msg // 发给主逻辑或广播协程
    }
}()

• 不要在读 goroutine 中直接调

  

  用 conn.Write()，否则可能和写 goroutine 冲突
• 如果需要响应式回写（比如 echo），把应答内容发到写 channel，由写 goroutine 统一发出
• conn.SetReadDeadline() 必须在每次 Read() 前设置，否则超时只生效一次

如何让服务端支持多客户端并广播消息

关键不是“怎么 accept”，而是“怎么管理活跃连接”。常见错误是把所有 conn 存进全局 slice 然后遍历 Write()，但没考虑连接已断开、写阻塞、或并发修改 slice 导致 panic。

推荐用 map + 互斥锁 + 心跳检测组合：

var (
    clients = make(map[*net.Conn]bool)
    mu      sync.RWMutex
)

• 每次 accept 后启动读/写 goroutine，并把 &conn 加入 clients（加写锁）
• 读 goroutine 收到 io.EOF 或其他错误时，从 clients 删除该连接（加写锁）
• 广播前用 mu.RLock() 遍历，对每个 conn 尝试非阻塞写（建议设 SetWriteDeadline 防卡死）
• 避免在广播循环中做耗时操作（如格式化字符串），提前准备好字节切片

bufio.Scanner 为什么在 TCP 聊天里容易丢消息

bufio.Scanner 默认以换行符分隔，适合终端输入，但不适合网络聊天：客户端可能不发 \n（比如 telnet 手动输入后按 Ctrl+D）、或者一次性发多条带 \n 的消息，导致 scanner 一次扫出多条，或因缓冲区满被截断。

• 生产环境更推荐用 bufio.Reader.ReadString('\n') 或直接 conn.Read() + 自定义分包逻辑
• 如果坚持用 Scanner，必须调大缓冲区：scanner.Buffer(make([]byte, 4096), 65536)
• 永远检查 scanner.Err()，而不仅是 scanner.Scan() 返回值；Err() 可能是 io.EOF（正常断开）也可能是 bufio.ErrTooLong（丢包信号）
• 不要用 scanner.Text() 直接拼接日志，它返回的是内部缓冲区引用，下次 Scan() 会覆盖内存

客户端如何优雅退出并通知服务端

Ctrl+C 杀进程时，TCP 连接不会立刻通知服务端，服务端要等 keepalive 或下一次读才感知断开——这期间用户已退出，但服务端还留着“僵尸连接”。

• 客户端退出前主动写一条协议消息（如 "QUIT\n"），再 conn.Close()
• 服务端读到该消息后立即清理连接，避免等待超时
• 服务端可配 SetKeepAlive(true) 和 SetKeepAlivePeriod(30 * time.Second) 加速探测死链
• 注意：Windows 对 SO_KEEPALIVE 行为较保守，Linux 更敏感；跨平台建议仍以应用层心跳为主

真正麻烦的从来不是“怎么连上”，而是“怎么确认对方还活着、有没有听清、听清了又有没有执行”。TCP 提供可靠传输，不提供可靠语义——聊天程序的边界，往往卡在协议设计那层。