net.Dial通过调用操作系统connect()系统调用触发内核完成TCP三次握手；conn.Close()对应四次挥手中的第一个FIN，进入FIN_WAIT_1状态。
Go 中 net.Dial 如何触发三次握手
net.Dial 并不直接发送 SYN 包，它只是发起阻塞式连接请求。底层调用的是操作系统 connect() 系统调用，该调用会触发内核协议栈完成 TCP 三次握手。如果对端未响应（如防火墙拦截、服务未监听），net.Dial 会在超时后返回 dial tcp <host>:<port>: i/o timeout</port></host> 错误。
关键点：
-
net.Dial默认无超时，建议始终传入带context.WithTimeout的context.Context，否则可能永久阻塞 - 若使用
net.DialTimeout，其内部仍调用connect()，只是封装了超时逻辑 - 握手过程完全由内核完成，Go 运行时无法干预 SYN/SYN-ACK/ACK 数据包内容
主动关闭时 conn.Close() 对应哪次挥手
conn.Close() 调用等价于向内核发出 close() 系统调用，内核立即发送 FIN 包，启动四次挥手的第一步（FIN）。此时连接进入 FIN_WAIT_1 状态。
常见误解：
立即学习“go语言免费学习笔记（深入）”；
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 它不是“断开连接”，而是“关闭本端写入方向”——对端仍可发数据（即还能读）
- 若对端已关闭写入，且你尚未读完剩余数据，
conn.Close()后仍可通过Read()取出缓冲区中已到达的字节 - 调用
Close()后再调用Write()会立即返回write: broken pipe或use of closed network connection
为什么有时 Close() 后立刻 Listen 会报 address already in use
这是 TIME_WAIT 状态导致的。主动关闭方（调用 Close() 的一方）在发送最后一个 ACK 后，会维持约 2×MSL（通常 60–120 秒）的 TIME_WAIT 状态，防止网络中滞留的旧包干扰新连接。
解决方式（按推荐顺序）：
- 服务端避免频繁主动关闭：让客户端关连接，服务端只负责
Accept和Read - 启用端口复用：
ln, err := net.Listen("tcp", ":8080")前设置&net.ListenConfig{Control: func(fd uintptr) { syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_REUSEADDR, 1) }} - 不推荐修改系统
/proc/sys/net/ipv4/tcp_fin_timeout—— 影响全局，且违反 TCP 规范
如何安全地实现连接半关闭与优雅退出
Go 标准库不暴露 shutdown(SHUT_WR)，因此无法单独关闭写入而保持读取（即 TCP 半关闭）。但可通过以下组合模拟语义：
conn.SetWriteDeadline(time.Now().Add(1 * time.Second))
n, err := conn.Write([]byte("bye"))
if err != nil {
// 写失败或超时，说明对端已关闭或不可达
}
// 此后不再 Write，但仍可 Read 直到对方 Close 或超时
for {
n, err := conn.Read(buf)
if err == io.EOF || err == io.ErrUnexpectedEOF {
break
}
if n > 0 {
// 处理数据
}
}
conn.Close() // 最终彻底关闭
注意：
- 没有真正的
shutdown(SHUT_WR)，所以对端收到 FIN 后若继续发数据，会触发 RST（而非正常 FIN） - 若需可靠半关闭语义，必须依赖应用层协议约定（例如发送特定结束帧）
- 生产环境建议配合
context控制整个生命周期，避免 goroutine 泄漏
TIME_WAIT 和半关闭缺失是 Go net.Conn 抽象层刻意为之的设计取舍，不是 bug。真正需要精细控制 TCP 状态的应用（如代理、负载均衡器），往往得绕过 net.Conn 直接操作文件描述符或使用 golang.org/x/net/bpf 等底层包。
