listen函数返回的listener不能直接读写，因为它只是net.Listener接口，仅含Accept()方法；真正收发数据的是Accept()返回的net.Conn实例，需在goroutine中处理并显式关闭。
listen 函数返回的 listener 为什么不能直接读写
因为 net.Listen 返回的是 net.Listener 接口，它只提供 Accept() 方法，不暴露底层连接的读写能力。真正承载数据收发的是 net.Conn——每次 Accept() 返回一个新连接实例，这才是你该操作的对象。
常见错误是试图对 listener 调用 Read() 或 Write()，会直接 panic：「undefined method Read」。正确流程必须是：监听 → 接受 → 处理单个连接。
- 使用
for循环持续调用listener.Accept()，阻塞等待新连接 - 每个
conn应该在 goroutine 中处理，否则后续连接会被卡住 - 记得 defer
conn.Close()，否则连接泄漏，系统 fd 耗尽后Accept()会失败并报错accept: too many open files
如何安全地并发处理多个 TCP 连接
Go 的 net 包本身不自动并发；Accept() 是同步阻塞的，但你可以手动启动 goroutine 处理每个 conn。关键点在于隔离连接生命周期，避免共享状态竞争。
典型结构是：for { conn, err := listener.Accept(); if err != nil { continue }; go handleConn(conn) }。这里 handleConn 必须接收 conn 值（不是指针），且内部完成全部读写和关闭逻辑。
- 不要把
conn存到全局 map 或 channel 再统一处理——容易忘记关、超时难控制、panic 会 kill 整个 server - 如果需要上下文控制（如超时、取消），用
net.Conn.SetDeadline()或包装成context.Context感知的 reader/writer - 注意：goroutine 泄漏比 fd 泄漏更隐蔽；确保所有路径（包括 error 分支）都调用了
conn.Close()
read 和 write 时遇到 EOF 或 timeout 怎么判断
conn.Read() 返回 (n int, err error)，EOF 不是异常，而是正常断连信号。当对端关闭连接（比如 client 调用 Close() 或进程退出），Read() 会立刻返回 n == 0 且 err == io.EOF。
而 timeout 是另一类错误：如果设置了 deadline（如 conn.SetReadDeadline(time.Now().Add(30 * time.Second))），超时后 Read() 返回 err == net.ErrDeadlineExceeded，此时连接仍有效，可继续用（除非你也主动关了它）。
- 区分
io.EOF和其他err != nil：前者可直接 break 循环并 close conn；后者（如网络中断、协议错误）建议 log 后也 close -
conn.Write()一般不会返回 EOF，但如果对端已关闭，下一次Write()可能触发broken pipe错误（write: connection reset by peer） - 不要依赖
n == 0判断 EOF ——某些场景（如空包、心跳）可能真读到 0 字节但连接还活着；必须检查err
为什么简单 echo 服务器上线后很快就卡死或拒绝新连接
最常见原因是没做连接管理：没有超时、没有限速、没有关闭闲置连接，导致大量半开连接堆积，或 goroutine 疯长耗尽内存/CPU。net 包不帮你做这些，全靠你自己加约束。
一个轻量但有效的防护是给每个连接设读写 deadline，并限制单次处理时间。例如在 handleConn 开头调用 conn.SetReadDeadline(time.Now().Add(60 * time.Second))，并在循环内每次 Read() 前更新。
- 避免用
time.Sleep替代 deadline —— 它会阻塞 goroutine，无法响应中断 - 如果业务需长连接，务必实现心跳检测（比如每 30 秒收一个 ping 包，超时两次就关掉）
- 别忽略
listener.Close()：服务退出时要先关 listener，否则Accept()可能还在阻塞，主 goroutine 无法退出
连接生命周期的边界非常清晰：从 Accept() 开始，到 conn.Close() 结束。任何中间环节的遗漏，都会变成资源泄漏或行为不可控。net 包只提供原语，不封装模式——这正是它轻量，也是它容易出错的地方。
