conn.Read() 不设超时会导致文件描述符泄漏，必须每次调用前用SetReadDeadline设置动态超时；写操作需读写分离+channel+WriteDeadline；启用SO_REUSEPORT防accept积压；禁用sync.Pool复用net.Conn或*os.File。
conn.Read() 不设超时会悄悄吃光文件描述符
Go 的 conn.Read() 默认永久阻塞，一旦客户端发完数据就挂起不关闭连接，这个 goroutine 就永远停在 net.(*conn).Read 上。它不 panic、不报错，但 fd 一直被占着——每个连接至少占用 1 个 socket fd，上千个“挂起但未关闭”的连接，lsof -p $PID | wc -l 就会突破系统限制，触发 too many open files。
必须每次调用前重置读超时：conn.SetReadDeadline(time.Now().Add(30 * time.Second))。注意别复用旧时间值，否则 deadline 越来越早，连接提前断开；HTTP/1.1 keep-alive 场景下可首次设置后不再重复，但得确保第一次调用成功。
- 错误类型是
*net.OpError，用os.IsTimeout(err)判断，不是字符串匹配"i/o timeout" - 空闲超时 ≠ 连接总时长超时，要配合
context.WithTimeout控制整个连接生命周期 - pprof 查
/debug/pprof/goroutine?debug=2，重点筛出阻塞在syscall.Read或net.(*conn).Read的 goroutine
写操作别直接 conn.Write()，否则竞争导致 fd 泄漏
多个 goroutine 并发调 conn.Write() 会破坏 socket 内部状态，轻则 panic 报 use of closed network connection，重则底层 fd 被意外关闭或复用失败，造成句柄泄漏——因为 Go 运行时在某些错误路径下无法保证 fd 归还内核。
标准解法是读写分离：一个 goroutine 专读，解析后发到带缓冲的 chan []byte；另一个 goroutine 专取、调 conn.Write()，并配 conn.SetWriteDeadline() 防卡死。
- channel 缓冲区大小建议 ≥ 16，太小容易阻塞读 goroutine；太大则内存积压，延迟不可控
- 写 goroutine 每次
conn.Write()后必须检查n != len(data)，未写全需重试或丢弃，否则残留数据会拖慢后续写入 - 写完记得关 channel：读 goroutine 在 close(conn) 前应
close(writeChan)，让写 goroutine 自然退出
SO_REUSEPORT 是防 accept 卡死的关键，不是可选项
单 listener + 单 goroutine 调 Accept() 是句柄耗尽的放大器：连接堆积在内核 listen queue，ss -s 显示 ListenOverflows 时，新连接直接被丢弃，客户端重试又新建更多连接，形成恶性循环。
必须用 net.ListenConfig{Control: func(fd uintptr) { syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1) }} 启动多个 listener goroutine（数量 ≈ runtime.NumCPU()），让内核分发连接，避免单点积压。
- Linux 3.9+ / Go 1.11+ 才支持；macOS 可用
SO_REUSEADDR+ 多 listener 模拟；Windows 需 fallback 到单 listener + 内部队列 - 别在 handler 里直接
Accept()后自己处理连接；应Accept()后立刻syscall.Dup()复制 fd，再交给 worker，避免 close 行为失控 - 启用
SO_REUSEPORT后，仍要监控lsof数量变化趋势，防止业务层逻辑（如忘记Close()）掩盖了底层优化效果
别碰 sync.Pool 复用 *os.File 或 net.Conn
*os.File 和 net.Conn 都含不可复制的内核 fd 和内部状态（偏移、锁、缓冲区），放进 sync.Pool 后取出可能已失效、关闭或被并发修改，极易触发 bad file descriptor 或数据错乱——这不是资源复用，是资源污染。
真正该做的是控制打开频率：批量读写优先走内存（io.ReadAll），长期连接用单例 + 读写锁管理生命周期，临时文件用 os.CreateTemp 并立即 os.Remove。
- 所有
os.Open*必须配defer f.Close()，哪怕只读一次；fd 是进程级资源，和文件大小无关 - http.Client 复用时，底层连接由
http.Transport管理，但若自定义DialContext或强制CloseIdleConnections()不当，也会导致 fd 积压 - 提高 ulimit 只是临时止痛，
ulimit -n 65536后仍出现耗尽，说明代码里有没关的 fd，得回溯lsof输出里的文件路径找根因
真正难的不是知道要设超时或开 SO_REUSEPORT，而是当 lsof 数量缓慢爬升、pprof 显示一堆 runtime.netpoll 时，你能快速判断是读 goroutine 没重置 deadline，还是写 goroutine 卡在未 flush 的 bufio.Writer 里，又或者某个第三方库偷偷 dup 了 fd 做阻塞调用——这些地方一漏，再多的并发模型也救不回句柄。
