net.DialTimeout 是最轻量的 TCP 连通性检测方式，仅完成三次握手，需按网络场景设合理超时（局域网300–500ms、同地域800ms–1.2s、跨地域2–3s），避免误判。
如何用 net.DialTimeout 判断目标服务是否可达
单纯靠 ping 无法反映应用层连通性，比如 HTTP 服务端口开着但进程已挂。更可靠的方式是尝试建立 TCP 连接。net.DialTimeout 是最轻量的检测入口，它不发送任何应用层数据，只完成三次握手。
常见错误是把超时设得太长（如 30 秒），导致监控毛刺明显；或设得太短（如 100ms），在高延迟网络下误判。建议按场景分级：
- 局域网内服务探测：300–500ms
- 同地域云服务器：800ms–1.2s
- 跨地域或公网 API：2–3s（需配合重试）
示例代码片段：
conn, err := net.DialTimeout("tcp", "example.com:80", 2*time.Second)
if err != nil {
// 连接失败，可能是端口关闭、防火墙拦截、DNS 不可达等
log.Printf("failed to dial: %v", err)
return false
}
defer conn.Close()
return true
为什么 http.Get 返回 200 不代表服务健康
http.Get 成功只说明 HTTP 协议栈响应了，但可能返回的是 Nginx 默认页、维护中页面、甚至 CDN 缓存的 200 响应。真实业务健康需要校验响应内容或状态码语义。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：必须设置 http.Client.Timeout，否则默认无超时，一次失败会卡住整个监控 goroutine；同时禁用重定向，避免跳转掩盖原始状态：
- 设置
Client.CheckRedirect = func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse } - 检查
resp.StatusCode是否为预期值（如 200、204），而非仅判断err == nil - 可选读取少量响应体（如前 1024 字节），验证是否含预期关键字（如
"status":"ok"）
如何避免 DNS 缓存干扰实时探测结果
Go 的 net.DefaultResolver 默认启用缓存（TTL），若目标域名解析记录变更（如切流量、故障转移），本地探测仍会持续打向旧 IP，造成误报。
解决方式不是关掉缓存，而是绕过默认 resolver，手动调用 net.LookupIP 并控制缓存逻辑：
- 每次探测前主动调用
net.LookupIP(host)获取最新 IP 列表 - 对每个返回的 IP 执行
net.DialTimeout("tcp", ip+":port", timeout) - 若全部失败才判定不可达，避免单点 IP 故障误伤
- 注意：不要复用
*net.Resolver实例做长连接，DNS 查询本身无连接态
并发探测多个地址时 goroutine 泄漏风险
用 go probe(target) 启动大量探测 goroutine 很容易失控——没有超时控制、没有等待机制、panic 未捕获，最终堆积成千上万僵尸 goroutine。
必须用带 cancel 的 context + waitgroup 统一收口：
- 每个探测任务启动前创建
ctx, cancel := context.WithTimeout(context.Background(), totalTimeout) - 在 goroutine 内部用
select { case 响应取消 - 主协程用
sync.WaitGroup等待全部结束，再统一cancel() - 禁止在探测函数里直接
log.Fatal或 panic，应返回 error 交由上层聚合处理
真正难的不是写一个能连上的函数，而是让几百个并行探测在任意失败、超时、网络抖动下都不崩、不漏、不积压。这些细节不压测根本看不出问题。
