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。你写的「状态」只是对已发生事件的被动记录，不是驱动行为的源头。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 真实 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 里的那个字节。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！