net.Dial 是 Go 中建立基础 TCP 连接的最直接方式，返回 net.Conn 接口，需显式设置超时、正确关闭、避免并发读写，并配合 deadline 机制保障可靠性。
如何用 net.Dial 建立基础 TCP 连接
Go 中最直接的 TCP 客户端连接方式是调用 net.Dial，它返回一个 net.Conn 接口，底层通常是 *net.TCPConn。注意它默认使用阻塞 I/O，且不自动重连。
- 基本写法：
conn, err := net.Dial("tcp", "127.0.0.1:8080", nil)—— 地址格式必须是host:port，不能省略端口或写成localhost:8080（虽然通常能解析，但 DNS 解析失败时会静默卡住） - 超时控制必须显式设置：直接传
&net.Dialer{Timeout: 5 * time.Second}，而不是依赖context.WithTimeout包裹net.Dial，否则 DNS 解析阶段仍可能超时失控 - 如果服务端未监听，
err通常是dial tcp 127.0.0.1:8080: connect: connection refused；若域名无法解析，则是lookup example.com: no such host
如何正确关闭并复用 net.Conn
TCP 连接不是“用完即弃”的资源，错误关闭会导致 TIME_WAIT 累积、端口耗尽或服务端无法及时感知断连。
- 务必在 defer 或明确逻辑出口处调用
conn.Close()；不关闭会导致 goroutine 泄漏（尤其在长连接场景） - 不要重复调用
Close()—— 第二次调用会返回use of closed network connection错误 - 连接关闭后，
conn.Read()会立即返回io.EOF，而conn.Write()返回write: broken pipe或类似错误，不能靠err == nil判断连接是否可用 - 如需连接池，别自己实现，优先用
http.Transport（对 HTTP）或封装sync.Pool+net.Conn（对自定义协议），注意池中连接需做SetDeadline校验存活
为什么 conn.SetReadDeadline 比 select + time.After 更可靠
在读取响应时，仅用 select 等待 conn.Read 和超时 channel，容易掩盖真实错误（比如连接已断但 Read 还没返回）。
-
conn.SetReadDeadline(time.Now().Add(10 * time.Second))会让下一次Read在超时后立即返回i/o timeout错误，且该 deadline 是 per-call 的，每次读前都得重设 - 不设 ReadDeadline 时，若对端静默断连（如直接拔网线），
Read可能永远阻塞（TCP keepalive 默认 2 小时才触发） - WriteDeadline 同理，尤其在高延迟或弱网下，避免因单次写卡住整个 goroutine
常见 panic 和静默失败场景
很多 TCP 问题不会立刻 panic，而是表现为连接卡住、读不到数据、或偶发性失败，根源常被忽略。
立即学习“go语言免费学习笔记（深入）”；
- 并发读写同一
net.Conn：Go 的net.Conn不是并发安全的，Read和Write不能同时进行，否则可能 panic 或数据错乱 —— 必须加锁或拆成 reader/writer goroutine - 忘记处理
io.EOF：它表示对端正常关闭，不是错误，但常被当成异常丢弃，导致业务逻辑中断 - 使用
bufio.Scanner读取无换行粘包数据：会直接Scan失败并终止，应改用bufio.Reader.ReadBytes或自定义分包逻辑 - 本地端口被占或 ephemeral port 耗尽：
dial tcp :8080: bind: address already in use或大量connect: cannot assign requested address，需检查netstat -an | grep TIME_WAIT | wc -l和系统net.ipv4.ip_local_port_range
TCP 连接管理真正的复杂点不在建立，而在生命周期判断与错误归因 —— 比如区分是网络中断、对端崩溃、还是防火墙拦截，这些都无法单靠 err 字符串判断，得结合 errors.Is(err, net.ErrClosed)、syscall.Errno 类型断言，以及应用层心跳反馈。
