Go net包提供贴近系统调用的原始能力，需明确TCP生命周期、端口绑定细节、Read字节流特性、连接安全关闭及分阶段超时控制。
Go 的 net 包不是“拿来即用”的抽象层，它提供的是贴近系统调用的、可组合的原始能力——直接暴露 TCP 连接生命周期、监听器控制权和底层地址解析逻辑。这意味着写对不难，但写稳、写健壮、写可维护，得清楚每一步在操作系统里触发了什么。
怎么用 net.Listen 启动一个 TCP 服务且不被端口占用卡住
net.Listen("tcp", ":8080") 看似简单，但实际部署常因端口复用、IPv6 绑定或权限问题失败。关键不是“能不能 listen”，而是“listen 后能不能立刻 accept”。
- 默认绑定
:::8080（IPv6+IPv4），若系统禁用 IPv6 或 Docker 容器网络配置受限，会静默 fallback 到 IPv4，也可能直接报bind: cannot assign requested address；显式指定"tcp4"或"tcp6"更可控 - 加
SO_REUSEADDR（Go 默认已启用）能避免 TIME_WAIT 占用端口导致重启失败，但无法绕过SO_REUSEPORT级别的多进程竞争——多个 Go 进程同时Listen同一地址仍会 panic - 监听前建议先用
net.InterfaceAddrs()检查目标 IP 是否本地可达，尤其在 Kubernetes 或多网卡环境中
为什么 conn.Read 有时读不到完整消息，甚至阻塞到超时
TCP 是字节流协议，Read 只保证返回「当前内核缓冲区里有的数据」，不保证是「一个业务包」。没有应用层协议约定（如长度前缀、分隔符），就不可能靠一次 Read 拿到完整请求。
- 常见错误：把
Read当作“读一行”或“读一个 JSON 对象”，结果遇到粘包或半包，解析直接 panic - 正确做法：要么用
bufio.Reader配合ReadString('\n')/ReadBytes('\n')处理行协议；要么自己实现定长头 + 变长体（例如先读 4 字节长度，再读对应字节数） - 注意
Read返回n, err：当n == 0 && err == nil是合法状态（对端写关闭但未关连接），不能直接跳过
如何安全关闭连接并避免 use of closed network connection
Go 不自动管理连接生命周期，conn.Close() 后若仍有 goroutine 在读写，就会触发这个错误。这不是竞态检测，而是运行时真实 panic。
立即学习“go语言免费学习笔记（深入）”；
- 必须确保所有对该
conn的读写操作都已退出：通常用sync.WaitGroup或context.WithCancel控制 goroutine 生命周期 - 不要在 handler 中直接
defer conn.Close()—— 如果 handler 因超时或 ctx.Done() 提前返回，defer仍会执行，但此时可能已有其他 goroutine 正在读写 - 推荐模式：启动两个 goroutine 分别处理读和写，用同一个
context.Context控制退出，并在两者都退出后再Close()
用 net.Dial 连接远程服务时，超时控制为什么总不生效
net.Dial 本身只控制 TCP 握手阶段超时；一旦连接建立，后续读写超时需单独设置，否则可能卡死在 Read 上数分钟。
-
net.DialTimeout已废弃，应改用&net.Dialer{Timeout: 5 * time.Second}构造 dialer - 连接建立后，必须显式调用
conn.SetDeadline/SetReadDeadline/SetWriteDeadline，否则默认无超时 - 注意：deadline 是绝对时间点，每次读写前都要重设；若用
SetReadDeadline(time.Now().Add(5*time.Second))，连续多次读需重复调用
真正难的从来不是“怎么连上”，而是“连上之后怎么知道它还活着、有没有丢数据、断了要不要重试、重试几次、用什么退避策略”。net 包只给你绳子，打什么结、系多紧、什么时候松开，全得自己想清楚。
