net.Conn 不会自动超时关闭空闲连接，因其不维护空闲时间概念，SetDeadline仅作用于下次读写；需应用层管理生命周期，HTTP场景用http.Server的IdleTimeout最稳妥，非HTTP场景需手动SetReadDeadline+心跳检测。
为什么 net.Conn 不会自动超时关闭空闲连接
Go 的标准库 net.Conn 本身不维护“空闲时间”概念，SetDeadline 系列方法只对下一次读/写生效，不会周期性检测连接状态。所以即使客户端断开、网络中断或进程挂起，服务端 net.Conn 仍可能长期处于 ESTABLISHED 状态，变成僵尸连接。
常见诱因包括：移动端休眠后未发 FIN、NAT 超时剪断底层链路但服务端无感知、客户端 panic 后未调用 Close()。
实操建议：
- 不要依赖 TCP keepalive（默认 2 小时才触发，远超业务容忍阈值）
- 必须在应用层实现连接生命周期管理，且需区分「连接建立时间」和「最后活跃时间」
- 避免用
time.AfterFunc为每个连接单独启 goroutine —— 十万连接 = 十万 goroutine，内存和调度开销爆炸
用 http.Server 的 IdleTimeout 和 ReadTimeout 最省事
如果你用的是 HTTP 协议（哪怕只是做长连接信道），直接配置 http.Server 是最稳妥的一键方案。它内置了连接池清理逻辑，且基于单个 net.Conn 的读写事件驱动，不额外占 goroutine。
立即学习“go语言免费学习笔记（深入）”；
示例关键配置：
srv := &http.Server{
Addr: ":8080",
Handler: myHandler,
ReadTimeout: 30 * time.Second, // 防止慢读耗尽连接
WriteTimeout: 30 * time.Second, // 防止慢写阻塞响应
IdleTimeout: 60 * time.Second, // 关键！空闲超时后主动关闭
}注意点：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
IdleTimeout从最后一次完成读/写操作开始计时，不是连接建立时间 - 必须搭配
Keep-Alive: timeout=60响应头（可选，用于提示客户端） - 如果用了反向代理（如 Nginx），要同步调大其
proxy_read_timeout，否则它先断连，Go 服务端还傻等
自定义 TCP server 时，用 conn.SetReadDeadline + 心跳检测
非 HTTP 场景（比如 WebSocket 底层、自定义二进制协议），需手动维护活跃状态。核心思路是：每次成功读取数据后重置读 deadline；定期发送心跳并等待 ACK；超时即关连接。
关键代码模式：
conn.SetReadDeadline(time.Now().Add(60 * time.Second))
for {
n, err := conn.Read(buf)
if err != nil {
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
// 真正的空闲超时，直接 break 并 Close()
break
}
// 其他错误（EOF、broken pipe）也该退出
break
}
// 处理 buf[:n] ...
// ✅ 每次读成功后，立刻刷新 deadline
conn.SetReadDeadline(time.Now().Add(60 * time.Second))
}容易踩的坑：
- 忘记在每次
Read成功后重置 deadline → 第一次读完就永远卡在超时 - 把
WriteDeadline和ReadDeadline混用 → 写超时不影响读计时，别指望靠写来续命 - 心跳包没加唯一 ID 或 ACK 机制 → 客户端丢包导致误判为离线
批量清理残留连接：用 runtime/pprof + net.Listener 状态扫描
上线后发现已有数万僵尸连接？不能重启服务时，得临时干预。Go 没提供直接枚举所有活跃 net.Conn 的 API，但可通过监听器 + 连接计数器 + pprof 辅助定位。
实操步骤：
- 启动时用原子变量记录所有
Accept到的连接：atomic.AddInt64(&connCount, 1)，defer atomic.AddInt64(&connCount, -1) - 暴露一个 debug HTTP 接口，返回
connCount和最近 100 条连接的RemoteAddr()+ 创建时间戳（需你自己存） - 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看是否大量 goroutine 卡在conn.Read—— 这是典型空闲连接堆积信号 - 极端情况下，可遍历你维护的连接 map，对 lastActive 时间 > 5 分钟的调用
conn.Close()（注意并发安全）
真正难的不是关连接，而是关之前确认它确实没在处理请求 —— 所以务必在连接对象上加状态字段（如 state uint32），用 atomic.CompareAndSwapUint32 控制关闭时机。
