直接调用 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）。
