用 net.dialtimeout 判断接口连通性最稳：仅建立 tcp 连接，超时可控（如 3 秒），不触发 dns/tls/http 上层逻辑；需指定端口、细判 net.opError 错误、加 dns 缓存、重复探测去抖、用 time.ticker 控制节奏、带 context 防 goroutine 泄漏、结构化日志与重试告警。
用 net.DialTimeout 判断接口连通性最稳
别用 http.Get 做连通性探测——它会等 DNS、TLS 握手、HTTP 头解析全完成，失败时长不可控，且无法区分是网络不通还是服务返回 503。真要测“端口能不能通”，就得回到 TCP 层。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
net.DialTimeout是唯一推荐的起点：只建 TCP 连接，超时由你定死（比如 3 秒），不触发任何上层协议逻辑 - 目标地址必须带端口，
"tcp", "api.example.com:443"不能写成"api.example.com"（默认端口不会自动补） - 错误类型要细判：
net.OpError表示网络层失败（如连接拒绝、超时），而*url.Error或http.*错误说明你误用了 HTTP 客户端 - 注意 DNS 缓存：golang 默认不缓存 DNS 结果，频繁调用会反复查，生产环境建议自己加
net.Resolver+ TTL 缓存
警报触发前必须做重复探测和状态去抖
单次 net.DialTimeout 失败就发告警？线上基本等于告警轰炸。瞬时丢包、服务端 SYN 队列满、本地 ephemeral port 耗尽都会导致偶发失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 连续 3 次失败才标记为“异常”，每次间隔 1–2 秒；成功一次立刻重置计数器
- 状态变更必须带“去抖”：从 “up → down” 或 “down → up” 切换时，强制等待 30 秒无变化再真正更新全局状态，避免毛刺翻转
- 记录最近 5 次探测耗时，如果平均延迟突增 300%，即使没超时也该预警（可能是链路拥塞或中间设备限速）
用 time.Ticker 而不是 time.Sleep 控制探测节奏
time.Sleep 在循环里用，一旦某次探测耗时 5 秒（超时设了 3 秒但实际卡住），下次探测就会延后，节奏彻底乱掉，监控曲线变成锯齿。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
time.Ticker固定每 10 秒 tick 一次，每次 tick 触发探测；探测本身异步 go 协程跑，不阻塞 ticker - 给每个探测 goroutine 加 context：超时时间 =
ticker.C下次触发前 1 秒，防止 goroutine 泄漏 - 别用
for range ticker.C直接处理：如果探测逻辑 panic，ticker 会卡住；外面包一层recover或用select+default非阻塞取值
发告警时别只扔个 fmt.Println
本地调试打日志没问题，但上线后没人盯着终端。真正的告警需要可追溯、可聚合、能静默。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 至少包含字段：
target（目标地址）、error（原始错误字符串）、latency_ms、occurred_at（UTC 时间戳） - 优先走标准输出（
log.printf），让运维用 log-agent 统一采集；别硬编码写文件路径，容易权限失败或磁盘打满 - 如果集成企业微信/钉钉，用 webhook 发送，但必须加重试（最多 2 次）+ 退避（第一次 1s，第二次 3s），否则网络抖动时告警全丢
- 所有告警消息末尾加唯一 trace ID，方便和 prometheus 的
probe_success指标对齐
探测逻辑看着简单，但真实环境里最常崩在 DNS 解析卡住、TCP TIME_WAIT 爆满、告警通道自身故障这三处。留个心眼，比加十个指标都管用。