Go 的 net.Conn 无法主动拦截 TCP RST，仅能在下次读写时返回“connection reset by peer”等错误；应启用 keepalive、设置读写超时、统一处理 RST 相关错误，并通过 context 控制 goroutine 生命周期防泄漏。
Go 的 net.Conn 无法主动拦截 TCP RST
TCP RST 是底层网络层的控制报文，Go 的 net.Conn 接口运行在传输层之上，对 RST 没有感知能力——它只会在下一次读/写时才暴露为 read: connection reset by peer 或 write: broken pipe。这不是 Go 的缺陷，而是 TCP 协议栈的设计使然。你没法在 RST 到达前“拦住它”，只能快速响应、不崩溃、不泄漏资源。
连接空闲时用 SetKeepAlive 和 SetKeepAlivePeriod 提前发现异常
攻击者常静默断开连接（如发 RST 后不发 FIN），服务端若长期不读写，会一直保留 goroutine 和 socket 资源。启用 keepalive 可让内核周期性探测对端是否存活：
-
conn.SetKeepAlive(true)开启系统级保活（Linux 默认 2h 后开始探测） -
conn.SetKeepAlivePeriod(30 * time.Second)将探测间隔缩到 30 秒（需 Go 1.19+；旧版本需设SO_KEEPALIVE+TCP_KEEPIDLE/TCP_KEEPINTVL通过syscall） - 注意：keepalive 不防 RST 本身，但能让连接在 RST 发生后几十秒内被标记为失效，避免堆积
读写操作必须带超时，并统一处理 net.ErrClosed 和 syscall.ECONNRESET
没有超时的 Read 或 Write 会永久阻塞或 panic；RST 触发的错误类型因平台而异，需兼容处理：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
conn.SetReadDeadline/SetWriteDeadline替代无超时调用 - 检查错误是否为
errors.Is(err, syscall.ECONNRESET)（Linux/macOS）或errors.Is(err, windows.WSAECONNRESET)（Windows） -
net.ErrClosed表示连接已被显式关闭，不是攻击信号，但和 RST 错误一样应立即退出 goroutine - 别用
err.Error()字符串匹配判断 RST——不同 Go 版本/系统返回文本可能变化
高并发场景下避免 goroutine 泄漏的关键是「读写分离 + context 控制」
一个典型陷阱：启动 goroutine 处理连接，但只在读循环里检查 ctx.Done()，写操作却无中断机制，导致 RST 后写 goroutine 卡死：
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout包裹整个连接生命周期，而非仅单次读写 - 读、写逻辑都应在 select 中监听
ctx.Done()，例如：select { case data := <-ch: conn.Write(data) case <-ctx.Done(): return // 立即退出 } - 对长连接服务，建议用
gobreaker或自定义熔断器，在连续出现ECONNRESET时临时拒绝新连接，防止雪崩
RST 本身不可防御，能做的只有缩短响应延迟、收紧资源生命周期、堵住 goroutine 泄漏路径——这些点一旦漏掉一个，攻击者几万个伪造 RST 就足以拖垮服务。
