net.Listener.Accept() 不该直接阻塞处理，而应每次 Accept 后用 goroutine 并发处理连接，避免串行化；关闭时需先关 listener、再等待活跃连接退出，HTTP 服务可用 http.Server.Shutdown 实现优雅关闭。
为什么 net.Listener.Accept() 不该放在 for 循环里直接阻塞处理
很多人写第一个 TCP 服务器时，会把连接处理逻辑直接塞进 Accept() 后的循环体里，比如：conn, _ := listener.Accept(); handle(conn)。这会导致新连接必须等前一个 handle() 执行完才能被接受，彻底串行化——哪怕 handle() 只是简单读一行就返回，也扛不住并发压测。
真正该做的是：每次 Accept() 到连接后，立刻启动一个 goroutine 去处理它。Go 运行时能高效调度成千上万个 goroutine，但前提是别让主线程卡在同步 I/O 或长耗时逻辑里。
-
Accept()必须始终在主 goroutine（或专用 accept goroutine）中调用，不能并发调用多个Accept() - 每个
conn应该交给独立 goroutine，例如：go handle(conn) - 记得在
handle()开头 deferconn.Close()，否则连接泄漏比内存泄漏更难排查
如何安全地关闭正在运行的 net.Listener 和活跃连接
服务升级或 SIGTERM 信号到来时，硬杀进程会导致连接中断、数据丢失、客户端重试风暴。Go 没有内置“优雅关闭 listener”的 API，得自己协调。
核心思路是：先关闭 listener，阻止新连接；再等待已有连接 goroutine 自行退出；最后才真正退出程序。
立即学习“go语言免费学习笔记（深入）”；
- 用
listener.Close()立即终止Accept()，后续调用会返回*net.OpError（err.Error()含"use of closed network connection"） - 用
sync.WaitGroup记录所有活跃handle()goroutine，handle()结束前调用wg.Done() - 不要依赖
conn.SetReadDeadline()来强制中断读取——它只影响下一次读，且可能掩盖真实 EOF
http.Server 的 Shutdown() 为什么比手写 TCP 服务器更容易优雅退出
如果你用的是 HTTP 协议，http.Server 内置了完整的优雅关闭支持，而裸 net.Listener 没有。关键在于 http.Server.Shutdown() 会主动通知所有活跃连接完成响应后再关闭，还提供超时控制。
它内部做了三件事：停止接收新请求、等待现存请求完成、关闭底层 listener。你只需传入一个 context 控制最大等待时间。
- 调用
server.Shutdown(ctx)前，确保已调用server.Close()或监听已启动 - context 超时不是“最多等这么久”，而是“如果还没结束就强制断开”，所以设太短会丢请求
- 若 handler 中启了额外 goroutine（如异步日志上报），需自行用
sync.WaitGroup或context传递取消信号
高并发下 net.Conn 读写不加锁却不会出问题？真相是什么
Go 的 net.Conn 接口本身不保证并发安全，但标准库实现（如 tcpConn）的读写方法（Read() / Write()）底层使用了文件描述符和系统调用，而 Linux 的 read()/write() 系统调用对同一个 fd 是线程安全的——但这不等于你可以随意并发读写同一个连接。
真正的问题不在系统调用层，而在应用层协议解析。比如两个 goroutine 同时 Read()，可能把一个完整 HTTP 请求拆成两半，导致解析失败；同时 Write() 可能打乱响应顺序。
- 对单个
conn，读和写操作应分别由**唯一 goroutine** 负责（常见模式：reader + writer + message loop） - 若需多处发消息，用 channel 把数据发给 writer goroutine 统一输出
- 不要因为“没 panic”就认为并发读写 conn 是安全的——它只是暂时没暴露竞态，一旦协议变复杂或负载升高，就会崩
连接生命周期管理比并发模型本身更易出错。尤其当业务逻辑嵌套了数据库调用、第三方 API、定时器时，goroutine 的存活时间变得不可控，这时仅靠 defer conn.Close() 远不够。
