直接调用 conn.Close() 会导致数据丢失，因其立即关闭 socket 而不等待发送缓冲区数据发出；正确做法是先 ShutdownWrite（或模拟）停止写入，再 SetReadDeadline 并循环 Read 直到 EOF 或超时，最后关闭连接。
为什么直接 conn.Close() 会导致数据丢失
Go 的 net.Conn 默认是“粗暴关闭”：调用 conn.Close() 会立即关闭底层 socket，无论发送缓冲区里还有没有未发出的数据，也不管对端是否已收到。尤其在高吞吐或弱网场景下，Write() 返回成功只代表数据进了内核发送缓冲区，不代表对方收到了——此时直接关连接，缓冲区残留数据就丢了。
真正需要的不是“立刻关”，而是“等发完再关”。这要求主动方先发 FIN（进入 FIN_WAIT1），但继续接收并处理对端可能发来的剩余数据（比如确认、响应或关闭请求），直到对方也关闭（收到 EOF）或超时。
- 客户端主动断开时，应先
ShutdownWrite()（Go 中需手动模拟）+ 等待读取完成 - 服务端通常不主动断，但若需主动终止某连接（如心跳超时），逻辑相同
-
SetDeadline()必须配合使用，否则Read()可能永久阻塞
用 SetDeadline() + 循环 Read() 等待对端关闭
Go 标准库没有直接暴露 shutdown(SHUT_WR)，但可通过设置写超时后强制关闭写入，并靠读循环等待对端 FIN 来模拟优雅断开。核心思路是：先停止写，再确保读完所有可用数据，最后关闭连接。
// 主动方优雅关闭示例
func gracefulClose(conn net.Conn) error {
// 1. 停止写入：设极短写超时，触发 Write() 失败，再关闭写方向（实际是关闭整个 conn，但读仍可用）
conn.SetWriteDeadline(time.Now().Add(10 * time.Millisecond))
// 尝试一次写（可选：用于冲刷缓冲区），忽略错误
conn.Write([]byte{})
<pre class="brush:php;toolbar:false;">// 2. 设置读超时，循环读直到 EOF 或超时
conn.SetReadDeadline(time.Now().Add(5 * time.Second))
buf := make([]byte, 1024)
for {
n, err := conn.Read(buf)
if n > 0 {
// 可选：处理残余数据（如协议头、心跳响应）
}
if err != nil {
if errors.Is(err, io.EOF) || errors.Is(err, net.ErrClosed) {
break // 对端已关闭
}
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
break // 读超时，认为对端无数据可发
}
return err
}
}
return conn.Close()}
立即学习“go语言免费学习笔记（深入）”；
- 不能依赖
Write([]byte{})一定触发 FIN；它只是尝试刷新缓冲区，真正 FIN 在Close()时发出 -
SetReadDeadline()是关键：避免因对端不发 FIN 导致永久阻塞 - 生产环境建议将读超时设为略大于最大预期响应时间（如 2~5 秒），而非固定 5 秒
服务端如何响应客户端的优雅断开请求
当客户端调用 shutdown(SHUT_WR)（如 Python 的 sock.shutdown(socket.SHUT_WR)）或 Go 客户端走上述流程时，服务端 Read() 会立即返回 io.EOF，而不是等到 Close()。这时服务端应停止写入、发送完应答后尽快关闭。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见误操作是：收到 io.EOF 后还继续 Write()，导致 write: broken pipe 错误。
- 必须在
Read()返回io.EOF后，检查是否还有待发送数据，有则发完再关 - 若协议允许，可在收到 EOF 前主动发完响应，然后调用
conn.Close() - 不要在
Read()出错后无条件重试Write()；先判断错误类型
更健壮的做法：结合 context 和连接状态管理
纯超时机制在长连接、心跳混合场景下容易误判。真实服务中推荐用 context.WithTimeout() 包裹整个关闭流程，并维护连接状态（如 isClosing 标志）防止并发 Close。
例如，在 HTTP/2 或自定义协议服务器中，可为每个连接启动 goroutine 处理关闭逻辑，用 sync.Once 保证只执行一次：
type trackedConn struct {
net.Conn
closeOnce sync.Once
mu sync.RWMutex
isClosed bool
}
<p>func (tc *trackedConn) GracefulClose(ctx context.Context) error {
tc.closeOnce.Do(func() {
tc.mu.Lock()
tc.isClosed = true
tc.mu.Unlock()</p><pre class="brush:php;toolbar:false;"> // 执行前述读清空逻辑，但用 ctx.Done() 替代超时判断
go func() {
select {
case <-ctx.Done():
tc.Conn.Close() // 强制关
}
}()
})
return nil}
立即学习“go语言免费学习笔记（深入）”；
真正难处理的是半开连接（连接已断但本端未感知）、NAT 超时、中间设备静默丢包——这些无法靠单次读写超时解决，必须依赖应用层心跳和重连机制。
