仅靠setreaddeadline无法清理只建连不发数据的僵尸连接，因其仅在read()调用时生效，而空闲连接永不触发读操作，导致established状态持续占用资源；必须在accept后立即设置首次读超时、启用tcp keepalive并配合信号量限流。
仅靠 SetReadDeadline 无法识别和清理海量只建连不发数据的僵尸连接——它只对后续 Read() 调用生效，而空闲连接根本不会触发读操作，会一直卡在 ESTABLISHED 状态，持续消耗文件描述符和内存。
为什么 accept 后不读就卡死
客户端 TCP 握手成功后立刻静默（如 NAT 后设备掉线、恶意扫描器建连即休眠），服务端 conn.Read() 永远不被调用，SetReadDeadline() 就没机会设置；此时连接既不报错也不释放，netstat -an | grep ESTABLISHED | wc -l 持续上涨，最终触发 “too many open files”。
- Go 的
net.Conn不自动探测对端是否存活，内核 TCP 状态仍为 ESTABLISHED，但路径已断 -
SetDeadline()和SetReadDeadline()都是 I/O 触发式超时，不是连接生命周期管理机制 - 主线程
listener.Accept()可能被阻塞，但更危险的是已接受连接却无人处理
必须在 Accept 后立即设首次读超时
只要连接建立完成，就要立刻为它绑定一个“首次心跳窗口”，强制在指定时间内收到首条数据，否则关闭。这不是业务逻辑超时，而是连接有效性验证。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在
go handleConn(conn)入口第一行就调用conn.SetReadDeadline(time.Now().Add(15 * time.Second)) - 这个 15s 是硬性窗口：客户端必须在此期间发送至少 1 字节（哪怕只是换行符），否则
Read()返回io.EOF或net.OpError，可安全关闭 - 不要等解析协议头再设 deadline——很多僵尸连接连 HTTP 方法都不会发
- 若业务允许，可在此阶段直接读 1 字节并丢弃：
buf := make([]byte, 1); conn.Read(buf)，再重置 deadline 进入常规流程
配合 TCP keepalive 防止中间设备单向断连
即使客户端发了数据，NAT 设备或 LB 可能在空闲 60–300 秒后单向清理连接，导致后续请求卡住。仅靠应用层首次超时不够，需操作系统级保活探针兜底。
- 对已升级为
*net.TCPConn的连接，立即启用：tcpConn.SetKeepAlive(true)和tcpConn.SetKeepAlivePeriod(45 * time.Second) - 注意：Linux 内核实际生效周期受
/proc/sys/net/ipv4/tcp_keepalive_time限制（默认 7200s），需提前调低该值才能让 45s 生效 - Go 1.19+ 支持
SetKeepAlivePeriod()，旧版本只能用SetKeepAlive()依赖系统默认（通常 2 小时） - keepalive 探针不占用应用层 buffer，但无法替代首次读超时——它不解决“连接建了但从不说话”的问题
用信号量 + context 控制并发连接总数
当僵尸连接大规模涌入（如 SYN flood 后半段建连成功），光靠单连接超时仍可能耗尽资源。必须在连接接入层做硬限流，避免 goroutine 和 fd 泛滥。
- 用带缓冲 channel 做连接准入闸门：
var connLimiter = make(chan struct{}, 500)，容量即最大并发连接数 - 在
Accept()循环中：select { case connLimiter - 在
handleConn结尾必须执行归还配额 - 搭配
context.WithTimeout包裹listener.Accept()，防 accept 本身卡死（如 fd 耗尽时返回syscall.EMFILE）
真正难处理的不是“连不上”，而是“连上了却不说话还赖着不走”。首次读超时 + TCP keepalive + 连接数硬限流，三者缺一不可——少任何一个，都可能在线上突然出现 fd 耗尽、goroutine 堆积或监控指标失真。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
