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><-sem - 别用
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 对应的处置动作完全不同。
