setdeadline不能解决空闲连接堆积，因其仅对下一次i/o生效且不触发于空闲状态；必须结合每次read后重设setreaddeadline、应用层心跳及连接数硬限等多层防护。
为什么 net.Conn.SetDeadline 不能直接解决空闲连接堆积
很多人第一反应是给每个 net.Conn 调用 SetDeadline 设个 30 秒超时，但这是错的——它只对下一次读/写操作生效，且每次 I/O 都要重设。如果连接长期空闲、中间没任何数据收发，deadline 就永远不会触发，连接就一直挂着。十万连接这么放着，file descriptor 和内存全被占满，accept 开始失败，服务就卡死了。
真正需要的是独立于 I/O 的「空闲心跳检测」：连接建立后，不管有没有数据来，只要连续 N 秒没收到任何有效业务数据，就主动关掉。
用 conn.SetReadDeadline + 心跳重置实现秒级空闲检测
核心思路是：在每次成功 Read 后，立刻调用 conn.SetReadDeadline 设置一个短 deadline（比如 10 秒），并把该 deadline 绑定到连接的生命周期里；一旦 Read 返回 io.EOF 或 net.ErrClosed，正常清理；一旦返回 os.IsTimeout 错误，说明空闲超时，立即 conn.Close()。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须在每次
Read成功后重设 deadline，不能只设一次 - 不要用
SetWriteDeadline做空闲判断——写操作不频繁，且写超时不等于空闲 - 避免在
goroutine里轮询time.Since(lastActive)，那会为十万连接开十万 goroutine，调度开销爆炸 - 推荐用
time.Timer或time.AfterFunc做单次延迟清理，但注意：必须用Timer.Stop()+Reset()配合每次读重置，否则 timer 泄漏
生产环境必须加的防护层：连接数硬限 + accept 限速
哪怕空闲检测逻辑完美，突发大量恶意空连接（比如 SYN flood 后半段握手完成但不发数据）仍可能瞬间打穿 fd 限制。Go 默认不限制 net.Listener 的并发连接数，得自己兜底。
- 用
net.ListenConfig的Control函数，在accept后检查当前活跃连接数，超阈值直接conn.Close()并continue - 对
Accept加简单令牌桶限速（例如每秒最多 500 新连接），用golang.org/x/time/rate.Limiter包，防止 accept 队列积压导致内核 backlog 溢出 -
ulimit -n必须提前调高，建议 ≥ 200000；Go 进程启动前检查syscall.Getrlimit(syscall.RLIMIT_NOFILE, &r)，不够就 panic 提示
别忽略 TLS 握手和 HTTP/2 的特殊空闲行为
如果你跑的是 HTTPS 或 gRPC（HTTP/2），空闲判断不能只看 TCP 层。TLS 握手完成后，客户端可能长期不发 HTTP 请求；HTTP/2 还有 PING 帧、SETTINGS 帧等控制流，它们不算“业务数据”，但说明连接还活着。
- 对于
http.Server，优先用内置的IdleTimeout字段（Go 1.8+），它会自动处理 HTTP/1.x keep-alive 和 HTTP/2 的空闲连接关闭 - 若自定义 TLS server，需在
tls.Conn上包装一层读逻辑，对tls.RecordHeader做解析，过滤掉 PING、SETTINGS 等帧后再判断是否空闲 - 千万别在 TLS handshake 完成前就设 read deadline——握手阶段的 timeout 应由
tls.Config.TimeOut控制，和业务空闲无关
空闲连接清理不是设个超时就完事，关键在「谁来触发、何时重置、怎么防爆」三个点。十万连接下，任何一个环节漏掉（比如忘了 Timer.Stop()，或没做 accept 限速），几秒内就会让机器进入假死状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
