如何使用Golang的net标准库_Golang TCP与UDP网络通信基础

直接调用 net.listen(“tcp”, “:8080”) 可监听所有本地ip的8080端口，需检查err、defer关闭listener、并发处理accept连接；udp无连接故无accept，须用readfrom/writeto；net.dial失败需区分错误类型并配合context控制超时；net.conn必须显式close，否则fd泄漏。

怎么用 net.Listen 启动一个 TCP 服务器

直接调用 net.Listen("tcp", ":8080") 就能监听本地所有 IP 的 8080 端口，但注意：端口号必须是整数字符串（如 ":8080"），不能写成 8080；如果端口被占用，会返回 "bind: address already in use" 错误。

常见疏漏点：

• 没检查 err 就直接用 listener，导致 panic
• 忘记用 defer listener.Close()，连接持续堆积后资源耗尽
• 在循环中用 listener.Accept() 接收连接，但没起 goroutine 处理，整个服务阻塞在单个连接上

基础骨架示例：

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(err)         continue     }     go handleConn(conn) // 必须并发处理 }

UDP 通信为什么不能用 Accept，得用 ReadFrom

TCP 是面向连接的，Accept 返回一个已建立的 net.Conn；UDP 是无连接的，没有“接受连接”这回事，所以 net.ListenUDP 返回的是 *net.UDPConn，只能靠 ReadFrom 和 WriteTo 收发数据包。

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

典型错误：

• 对 UDPConn 调用 conn.Read() —— 会报 "use of closed network connection" 或直接阻塞（取决于是否已关闭）
• 用 WriteTo 时传入的地址不是 *net.UDPAddr，比如错用 net.ParseIP 返回的 net.IP，导致 "invalid argument"
• 没预分配足够大的缓冲区（如只开 16 字节），导致 UDP 包被截断且不报错

最小可用 UDP 服务片段：

addr, _ := net.ResolveUDPAddr("udp", ":9999") conn, _ := net.ListenUDP("udp", addr) defer conn.Close()  buf := make([]byte, 1500) // UDP 常见 MTU 上限 for {     n, clientAddr, err := conn.ReadFrom(buf)     if err != nil {         log.Println(err)         continue     }     conn.WriteTo(buf[:n], clientAddr) }

net.Dial 连接失败时，常见错误类型和重试逻辑怎么写

net.Dial("tcp", "example.com:80") 失败时，err 通常是 *net.OpError，其 Err 字段才包含底层原因，比如 "i/o timeout"、"connection refused" 或 "no such host"。直接判断 err == nil 不够，要区分可重试与不可重试错误。

建议做法：

• 超时类错误（os.IsTimeout(err) 或检查 err.Error() 是否含 "timeout"）可重试
• "connection refused" 说明服务未启动，重试意义不大，除非你控制服务启停节奏
• DNS 解析失败（"no such host"）通常不该重试，而是检查域名或 DNS 配置
• 务必设置 context.WithTimeout，避免 Dial 卡死（默认无超时）

带上下文的拨号示例：

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() conn, err := net.DialContext(ctx, "tcp", "httpbin.org:80",) if err != nil {     // 检查是否超时     if ctx.Err() == context.DeadlineExceeded {         log.Println("dial timeout")     }     return }

为什么 net.Conn 的 Close 必须显式调用，且不能只依赖 GC

Go 的 GC 不会自动关闭网络连接，net.Conn 底层持有操作系统文件描述符（fd），不 Close 就会泄漏。linux 默认每个进程最多打开 1024 个 fd，一旦耗尽，新连接会直接失败并报 "too many open files"。

容易被忽略的场景：

• HTTP handler 中用 http.DefaultClient 发请求，但没设置 Transport 的 MaxIdleConns，空闲连接长期不释放
• UDP 场景下反复 net.DialUDP 却没 Close()，每个 dial 都占一个 fd
• 在 defer 中 Close()，但函数提前 return 了，defer 没执行到（比如 panic 后 recover 但没再 close）

安全写法：在连接使用完毕后立即 Close，不要依赖作用域结束或 GC；对关键路径，可用 runtime.SetFinalizer 做兜底（仅作辅助，不能替代主动 close）。