go中tcp连接状态无法通过net.conn获取，需依赖系统工具如ss或/proc/net/tcp解析；应用层应以read/write错误判断连接实际可用性，而非模拟内核状态。
Go 里 TCP 连接的状态不是靠 net.Conn 自身暴露的
Go 标准库的 net.Conn 接口是抽象的，它不提供任何获取底层 TCP 状态（如 ESTABLISHED、CLOSE_WAIT）的方法。你调用 conn.RemoteAddr() 或 conn.LocalAddr() 只能拿到地址信息，不是连接状态；conn.SetDeadline() 也不检查状态，只影响 I/O 阻塞行为。
真正能反映 TCP 状态的，只有操作系统内核维护的那一套——Go 不直接透出，得绕道系统工具或 syscall。
- Linux 下可读取
/proc/net/tcp或/proc/net/tcp6，解析十六进制状态字段（如01表示ESTABLISHED，07是CLOSE_WAIT） - macOS/BSD 需用
lsof -iTCP -n -P或netstat -an -p tcp，再文本解析 - 跨平台统一获取？基本不存在。别指望
net.Conn加个方法就能返回TCP_ESTABLISHED
想在 Go 服务中感知连接异常，别等状态码，盯住 Read 和 Write 的错误
TCP 连接“看起来还活着”，但对应用层来说，真正有意义的状态只有三个：可读、可写、已断。Go 程序不该去查 /proc，而应通过 I/O 行为判断。
-
Read返回io.EOF→ 对端关闭了写入（常见于 FIN 包到达） -
Read返回net.OpError且Err是syscall.ECONNRESET或syscall.EPIPE→ 对端异常终止（RST 包） -
Write返回net.ErrClosed→ 连接已被本地关闭（比如conn.Close()后还写） - 超时不是状态，而是配置：用
SetReadDeadline+SetWriteDeadline控制阻塞等待上限，避免 goroutine 卡死
状态模式在 Go 中模拟 TCP 状态机，容易掉进「过度设计」坑
有人想用状态模式封装 SYN_SENT→ESTABLISHED→FIN_WAIT1… 实际上没意义。Go 的 net.Conn 不让你控制握手细节，也不能主动发 RST 或重发 SYN。你写的「状态」只是对已发生事件的被动记录，不是驱动行为的源头。
立即学习“go语言免费学习笔记（深入）”；
- 真实 TCP 状态由内核管理，用户态 Go 程序无法干预其流转
- 所谓「状态对象」最后往往退化成一个带字符串字段的 struct：
type ConnState struct{ Name string }，纯属冗余 - 如果真要建模，只应在协议解析层用（比如实现自定义 TCP-like 协议），而不是套在标准
net.Conn上 - 更实用的做法：用 map 记录活跃连接 + 最后活动时间，配合定时器做空闲清理
调试时看真实 TCP 状态，优先用 ss -tn 而不是 netstat
netstat 在多数现代 Linux 发行版里已被废弃，输出慢、精度低、不支持新 socket 类型。ss 是 iproute2 套件的一部分，直接读取内核 socket 表，快且准。
-
ss -tn state established→ 查所有 ESTABLISHED 连接 -
ss -tn src :8080→ 查本地 8080 端口上的连接 - 状态缩写：
estab、fin-wait-1、time-wait、close-wait，注意大小写不敏感但不能简写成close - Go 程序里想自动采集？可以用
exec.Command("ss", "-tn")，但注意权限和容器环境里可能没有ss
内核看到的才是真的，代码里写的“状态”只是猜测。别让结构体名字误导你——TCPState 不等于 /proc/net/tcp 里的那个字节。
