直接结论：用 time.Ticker，但必须配合手动控制启动/停止和错误重试逻辑。time.AfterFunc 递归调用易失控，无法统一 cancel；ticker 可绑定服务生命周期、支持 Stop()，且利于统一调度与熔断。
轮询函数该用 time.Ticker 还是 time.AfterFunc？
直接结论：用 time.Ticker，但必须配合手动控制启动/停止和错误重试逻辑。用 time.AfterFunc 递归调用容易失控——一旦某次健康检查卡住或 panic，后续调度就彻底断掉，且无法统一 cancel。
常见错误现象：time.AfterFunc 嵌套调用后，服务重启时旧 ticker 没被 stop，新 ticker 又起一个，导致并发检查翻倍；或者某次 HTTP 请求超时未设 context.WithTimeout，整个 goroutine 卡死，AfterFunc 再也不触发。
-
time.Ticker提供明确的Stop()方法，可与服务生命周期绑定（如http.Server.Shutdown时同步 stop） - 每次轮询应封装在独立 goroutine 中，避免单次失败阻塞下一轮（
go checkOneServer(...)） - 轮询间隔建议设为 5–30 秒之间；太短加重集群压力，太长无法及时发现故障
健康检查接口返回异常时，怎么区分「临时抖动」和「真实宕机」？
不能只看单次 HTTP 状态码。比如 502 Bad Gateway 可能是反向代理暂时不可达，而 0 响应码（连接拒绝）大概率是目标进程已死。
实操建议用「连续失败计数 + 指数退避」组合判断：
立即学习“go语言免费学习笔记（深入）”；
- 每个服务器维护一个
failCount int字段，每次检查失败则 +1；成功则重置为 0 - 只有
failCount >= 3且最近一次失败距今 > 30 秒，才标记为Down - 对连续失败的节点，下次检查前 sleep
min(2^failCount * 100, 5000) ms，避免雪崩式重试 - 务必记录原始错误：是
net.OpError（连不上）、http.ErrHandlerTimeout（响应超时），还是io.EOF（服务主动断连）？类型不同，恢复策略也不同
如何避免轮询 Goroutine 泛滥？
每台服务器起一个 goroutine 轮询？错。100 台机器 = 100 个常驻 goroutine，内存和调度开销不小，尤其当检查逻辑含锁或 channel 操作时，容易成为瓶颈。
更合理的做法是「单 goroutine 多路复用」：
- 用一个全局
time.Ticker触发统一调度器，每次 tick 遍历所有服务器列表，按权重或顺序轮询若干台（例如每次最多检查 5 台） - 服务器列表用
sync.Map存储，键为host:port，值含状态、最后检查时间、failCount 等字段 - 检查任务本身仍用 goroutine 异步执行，但由调度器统一分配，避免数量失控
- 如果集群动态扩缩容，更新服务器列表时需加读写锁（
sync.RWMutex），但只在增删节点时写，轮询时仅读，性能影响可控
HTTP 健康检查要不要带 Authorization 或 TLS 验证？
要，但必须分开配置。生产环境里，健康检查端点往往和业务端口共用，但权限模型完全不同——你不可能让监控系统持有业务 JWT，也不该把业务证书暴露给轮询器。
正确姿势：
- 为健康检查单独开一个监听端口（如
:8081/healthz），不走业务中间件链路，绕过 auth、rate limit 等逻辑 - 若必须走 HTTPS，用专用 client：禁用证书校验（
tls.Config.InsecureSkipVerify = true）仅限内网；外网则配轻量 CA 证书，别复用业务证书 - 避免在请求头塞
Authorization: Bearer xxx—— token 过期或轮换时，健康检查会批量误报；改用静态 token 或 IP 白名单更稳妥 - 检查响应体必须验证内容，不只是状态码。比如返回
{"status":"ok","uptime":12345}，就解析 JSON 看status字段，防止 Nginx 返回 200 却塞了个 maintenance 页面
最易被忽略的点：轮询器自身没有熔断机制。当集群大面积失联时，它还在拼命重试，可能拖垮本机资源。上线前务必加上全局失败率统计和自动暂停开关。
