Golang如何创建TCP服务器_Golang socket编程实战

listen后必须调用accept接收连接，否则客户端connect会超时或被拒绝；需用for循环持续accept并为每个conn启goroutine处理；Read/Write须处理EOF和部分读写；应设deadline防goroutine泄漏；根据需求选tcp4/tcp6而非默认tcp。

listen 之后必须用 accept 接收连接，否则客户端 connect 会超时失败

Go 的 net.

Listen 只是打开监听端口并返回一个 net.Listener，它不会自动处理新连接。你得手动调用 Accept 才能拿到客户端的 net.Conn。漏掉这一步，客户端发起 connect 后会卡在 SYN_SENT 或直接返回 “connection refused”（如果端口未监听）或 “timeout”（如果监听了但没 accept）。

常见写法是用 for 循环持续 Accept：

l, err := net.Listen("tcp", ":8080")
if err != nil {
    log.Fatal(err)
}
defer l.Close()
for {
conn, err := l.Accept()
if err != nil {
log.Println("Accept error:", err)
continue // 不要 panic，继续尝试下一次 accept
}
go handleConn(conn) // 每个连接启一个 goroutine 处理
}

• Accept 是阻塞调用，除非监听器被关闭或出错，否则不会返回 nil conn
• 务必启动 goroutine 处理每个 conn，否则后续连接会被阻塞在 Accept —— Go 的 Listener 默认不带连接队列并发处理能力
• 注意检查 err：网络抖动、文件描述符耗尽等都可能导致 Accept 失败，不能忽略

read 和 write 必须处理 EOF 和 partial write，不能假设一次调用完*部数据传输

TCP 是流式协议，conn.Read 和 conn.Write 都可能只读/写部分数据。尤其在高负载、小包、跨设备场景下，Read 返回 n 很常见；Write 也可能只写出部分字节，甚至返回 nil 错误但 n 。

典型错误写法：

// ❌ 错误：没检查 n，也没处理 EOF 或 partial write
var buf [1024]byte
n, _ := conn.Read(buf[:])
conn.Write(buf[:n])

正确做法应循环读直到 io.EOF，或按协议定义消息边界（如长度前缀）；写则需确保全部字节发出：

// ✅ 安全读一行（适合简单协议）
msg, err := bufio.NewReader(conn).ReadString('\n')
if err == io.EOF {
    return // 客户端断开
}
if err != nil {
    log.Println("Read error:", err)
    return
}
// ✅ 安全写全部
_, err = io.WriteString(conn, "OK\n")
if err != nil {
log.Println("Write error:", err)
return
}

• 用 bufio.Reader / bufio.Writer 简化行或缓冲操作，但注意它们内部仍调用底层 Read/Write
• 自定义协议时，别依赖“一次 Read 拿到整包”，必须解析长度头或分隔符
• Write 返回 n 且 err == nil 是合法状态，需手动补写剩余部分（io.Copy 或循环 Write）

goroutine 泄漏比想象中容易：conn.Close 后仍可能有 pending read/write

很多人以为 conn.Close() 调用后，关联的 goroutine 就安全退出了。实际上，如果该 goroutine 正在阻塞于 Read 或 Write，它不会立即醒来——除非设置 deadline 或使用 SetDeadline / SetReadDeadline。

例如这个 handler：

func handleConn(conn net.Conn) {
    defer conn.Close()
    buf := make([]byte, 1024)
    for {
        n, err := conn.Read(buf)
        if err != nil {
            return // 这里可能永远等不到 err，goroutine 挂起
        }
        // ... 处理逻辑
    }
}

当客户端异常断网或主动 close，服务端 Read 可能长时间不返回，goroutine 无法释放。

• 给连接设读写 deadline：conn.SetReadDeadline(time.Now().Add(30 * time.Second))
• 用 context.WithTimeout 包裹整个处理流程，配合 conn.SetReadDeadline 实现可取消 I/O
• 不要在 defer 里只写 conn.Close()，还要考虑是否需要显式中断阻塞操作（比如用 conn.SetReadDeadline 触发 timeout）

Listen 使用 "tcp" 还是 "tcp4"/"tcp6"？本地测试和容器部署表现不同

net.Listen("tcp", ":8080") 在多数系统上默认监听 IPv4 和 IPv6（双栈），但行为取决于 OS 和内核配置。Linux 上若未开启 net.ipv6.bindv6only，它可能只绑 IPv6 地址却接受 IPv4 连接（IPv4-mapped IPv6）；而某些容器环境（如 Docker 默认 bridge）或 Windows 可能只暴露 IPv4，导致 "tcp" 绑定失败或不可达。

明确需求再选协议名：

• 只要 IPv4：net.Listen("tcp4", ":8080") —— 更稳定，兼容性最好
• 强制 IPv6：net.Listen("tcp6", ":8080") —— 注意地址字面量要加方括号，如 [::1]:8080
• 双栈且需精确控制："tcp" + 检查 l.Addr() 类型，或用 net.ListenConfig{Control: ...} 设置 socket 选项

调试时可用 ss -tlnp | grep :8080（Linux）或 netstat -anv | findstr :8080（Windows）确认实际监听的是 *:8080 还是 :::8080 —— 这直接影响能否从 localhost 或 127.0.0.1 访问。

真正麻烦的是：同一个端口，"tcp4" 和 "tcp6" 可以同时 listen，但 "tcp" 和其中任一叠加会报 address already in use。上线前务必在目标环境验证绑定结果。