必须通过i/o行为推断tcp连接状态，而非依赖状态码或底层socket细节；启用keepalive、定期心跳、合理设置超时与重连策略才是可靠方案。
怎么用 net.Conn 感知 TCP 连接是否真的断开了
Go 的 net.Conn 接口本身不暴露底层 TCP 状态，Read() 和 Write() 也不会立刻返回连接已关闭——它可能卡在半开状态（如对端静默掉线），或 linger 未完成。你不能靠 conn == nil 或一次 Read() 返回 io.EOF 就判定“已断开”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须启用
SetKeepAlive(true)并调低SetKeepAlivePeriod()（例如30 * time.Second），否则内核默认 2 小时才探测死链 - 不要只依赖
Read()返回错误；对关键连接，定期发心跳包（如write + read组合），并设SetDeadline()防止阻塞 -
conn.RemoteAddr().String()始终可用，但不反映当前连通性；真正判断要用 I/O 行为驱动
为什么 net.Conn 没有 State() 方法，而 syscall.GetsockoptInt() 又不跨平台
Go 故意抽象掉 TCP 状态机细节，因为 ESTABLISHED/CLOSE_WAIT 这类状态是内核 socket 层的瞬时快照，用户层读到的值可能在返回前就变了；且 Windows 的 WSAIoctl(SIO_QUERY_RCVBUF) 和 Linux 的 getsockopt(TCP_INFO) 结构完全不同。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别试图用
unsafe或syscall手动读TCP_INFO来轮询状态——Linux 下字段偏移易变，Go 1.21+ 已弃用部分syscall常量 - 如果真要观察状态迁移，改用
ss -tien或cat /proc/net/tcp配合外部监控脚本，而不是嵌入 Go 业务逻辑 - 接受“连接状态只能通过 I/O 行为推断”这个事实，把精力放在超时控制和重连策略上
net.Conn.Close() 调用后，为什么还能读到数据？
这是 TCP 半关闭（FIN）语义导致的：调用 Close() 只表示本端不再发送，但对端可能还有未读完的数据。Go 的 Read() 会继续返回这些残留数据，直到收到 FIN 或超时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Close()后仍需循环Read()直到返回io.EOF或超时，否则可能丢数据 - 若需强制终止双向通信，用
SetDeadline(time.Now())再Read()一次，触发syscall.EINVAL或io.ErrUnexpectedEOF - 注意
Close()不等于 “连接立即消失”，TIME_WAIT 状态由内核维护，Go 程序无法干预
如何在 HTTP/2 或 gRPC 场景下间接追踪底层 TCP 状态
HTTP/2 复用 TCP 连接，gRPC 默认走 http2.Transport，它们都屏蔽了原始 net.Conn。你没法直接调用 SetKeepAlive()，也不能监听 Read() 错误——所有 I/O 被封装进流控和帧处理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对
http.Client，设置Transport.IdleConnTimeout和Transport.KeepAlive（后者对应底层 socket 的 keepalive） - gRPC 的
grpc.WithKeepaliveParams()是唯一可控入口，其中Time字段传给SetKeepAlivePeriod()，Timeout控制探测失败后多久断开 - 别依赖
grpc.ClientConn.State()的返回值（如CONNECTING、READY）来判断 TCP 是否存活——它只反映 gRPC 自身连接池状态，不是 socket 级别
真正难的不是获取状态，而是接受“TCP 状态不可靠”这个前提：网络没有绝对的在线/离线，只有“最近一次 I/O 是否成功”。所有监控逻辑都要围绕可验证的行为（读、写、超时）来建模，而不是某个瞬间的状态码。
