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。
