如何在Golang中编写一个监控特定端口的脚本 Go语言网络连接状态检查

net.dialtimeout 是检查 tcp 端口连通性最直接可控的方案，需显式设置 2–5 秒超时，通过类型断言 net.opError 并比对错误码（如 econnrefused 或 timeout）区分拒绝连接与超时，避免阻塞和误判。

用 net.DialTimeout 检查端口连通性最直接

go 标准库没提供“ping 端口”这种封装函数，net.DialTimeout 是最轻量、最可控的方案。它不依赖 ICMP，而是尝试建立 TCP 连接，行为贴近真实服务可用性判断。

常见错误是直接用 net.Dial 不设超时，一旦目标主机防火墙丢包或服务未监听，会卡住默认 30 秒（取决于系统 TCP connect timeout），脚本彻底阻塞。

• 必须显式传入 time.Second * 3 这类超时值，建议 2–5 秒之间
• 只适用于 TCP；udp 端口检测需用 net.ListenUDP + 发包收包逻辑，复杂度高且不可靠，一般不推荐
• 返回 nil 表示连接成功，否则检查错误类型：net.OpError 的 Err 字段是否为 timeout 或 connection refused

区分 connection refused 和超时的关键在错误判断

两者都表示端口不通，但原因不同：前者说明目标主机可达、端口明确拒绝连接（服务未启动）；后者可能是网络中断、防火墙拦截、中间设备丢包，或服务进程僵死无响应。

直接用 err.Error() 匹配字符串容易出错（比如某些系统返回本地化错误）。正确做法是类型断言 + 错误码比对：

立即学习“go语言免费学习笔记（深入）”；

if opErr, ok := err.(*net.OpError); ok {     if opErr.Err != nil {         if opErr.Err == syscall.ECONNREFUSED {             // 明确被拒         } else if opErr.Timeout() {             // 超时         }     } }

• windows 下需引入 golang.org/x/sys/windows 并用 windows.WSAECONNREFUSED
• Linux/macos 可用 syscall.ECONNREFUSED，但注意 syscall 包已弃用，生产环境建议用 x/sys/unix
• 别忽略 opErr.Err == nil 的情况（如 DNS 解析失败），此时 opErr.Timeout() 会 panic

批量监控多个端口时避免 Goroutine 泄漏

写 for 循环起 goroutine 调用 net.DialTimeout 很常见，但若不控制并发数或不回收 channel，容易打爆文件描述符或内存泄漏。

• 用带缓冲的 channel 控制并发，例如 sem := make(chan Struct{}, 10)，每次执行前 sem ，结束后 <code>
• 别用 go func() { ... }() 直接闭包捕获循环变量，会导致所有 goroutine 共享最后一个 addr 值；应传参：go func(addr string) { ... }(addr)
• 结果收集建议用 sync.WaitGroup + map[string]bool，而不是无缓冲 channel —— 否则某次 dial 卡住会导致后续结果无法写入 channel

容器或 Kubernetes 环境下注意 DNS 和网络命名空间

脚本在宿主机跑没问题，一进容器就全连超时？大概率是 DNS 解析失败或网络模式导致地址不可达。

• 别硬编码 "localhost:8080" —— 容器里 localhost 指自身，不是宿主机；该用 "host.docker.internal:8080"（Docker Desktop）或宿主机真实 IP
• K8s Pod 内访问 Service，优先用 ServiceName.Namespace.svc.cluster.local:Port，避免依赖 /etc/hosts 静态映射
• Alpine 镜像默认无 /etc/resolv.conf 或 DNS 配置错误，net.DialTimeout 会卡在 DNS 查询阶段，超时时间实际是 DNS 超时 + 连接超时之和

端口监控真正的难点不在 Dial 这一行代码，而在错误归因——你得快速分清是服务挂了、网络断了、DNS 翻车了，还是脚本自己没设对超时。每种 case 对应的处置动作完全不同。