应使用独立 goroutine 轮询而非 http.Server：因需主动探测下游服务，须用 time.NewTicker 启动带 recover 和超时控制的 goroutine，各协议实现 Checker 接口统一管理，双保险设置 context.WithTimeout 与 http.Client.Timeout，并通过状态机聚合结果。
健康检查服务该用 http.Server 还是独立 goroutine 轮询？
直接用 http.Server 暴露 /health 端点只能反映本机进程是否存活，没法探测下游服务。真要监控多个外部服务（比如 https://api.example.com、redis://localhost:6379），必须主动发起探测——这意味着得开 goroutine 定时跑检查逻辑，而不是靠 HTTP 请求触发。
常见错误是把健康检查写成 HTTP handler 里同步拨号，结果一次请求卡住整个 handler；或者用 time.Tick 在 main goroutine 里死循环，没做 recover 导致 panic 崩溃后无人重启。
- 用
time.NewTicker启动独立 goroutine，每次 tick 触发一轮全量探测 - 每个探测任务加超时控制：HTTP 用
http.Client{Timeout: 5 * time.Second}，Redis 用ctx, cancel := context.WithTimeout(ctx, 3*time.Second) - 所有 goroutine 启动前套
go func() { defer recover() ... }()，避免单个 panic 杀死整个监控器
怎么统一管理不同协议的服务探测逻辑？
HTTP、gRPC、TCP、Redis、PostgreSQL 的探测方式完全不同，硬写 if-else 容易散落在各处，改一个协议就得翻三四个文件。最省事的做法是定义一个接口，让每种类型实现自己的 Check() 方法。
比如定义 type Checker interface { Check() error }，然后为 HTTP 写 HTTPChecker，为 Redis 写 RedisChecker，它们各自封装连接、认证、探活逻辑。主循环只管调 c.Check()，不关心底层怎么连。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- HTTP 探测别只 GET
/，优先用HEAD减少服务端负担；若目标要求鉴权，记得传Authorizationheader - TCP 探测用
net.DialTimeout("tcp", addr, 2*time.Second)就够，不用发任何数据 - gRPC 探测不要直接 Dial，用
grpc.Dial(..., grpc.WithBlock(), grpc.WithTimeout(3*time.Second))，否则可能卡在 DNS 解析或连接排队上
context.WithTimeout 和 http.Client.Timeout 有什么区别？
两者都控制超时，但作用层级不同：http.Client.Timeout 是整个请求生命周期上限（DNS + 连接 + TLS + 发送 + 接收），而 context.WithTimeout 是对某次调用的总时限，还能被提前取消（比如收到 SIGTERM 时优雅退出）。
实际用的时候必须双保险：既设 http.Client.Timeout 防止底层卡死，又用 context.WithTimeout 包裹 client.Do(req.WithContext(ctx))，这样 shutdown 信号才能及时中断正在跑的请求。
- 单独依赖
http.Client.Timeout会导致程序收到 kill 信号后仍等待当前请求自然超时，无法快速退出 - 单独依赖
context.WithTimeout但http.Client.Timeout设为 0（默认），可能因 DNS 解析失败卡住几十秒 - 推荐组合：
http.Client{Timeout: 8 * time.Second}+context.WithTimeout(ctx, 10*time.Second)，后者比前者略宽裕，留出上下文切换开销
状态聚合和上报容易漏掉什么？
探测结果不能只存在内存里，得能查、能告警、能存历史。最容易忽略的是「状态漂移」：某个服务连续失败 3 次才判定为宕机，但中间有一次成功，状态就重置了——这会让抖动服务看起来永远“健康”。
简单做法是用 map 记录每个服务最近 N 次结果，按失败率算健康分；更稳的做法是引入状态机（如 UP → DEGRADED → DOWN），配合持续失败计数器和恢复冷却期。
- 别把原始探测日志全打到 stdout，用结构化日志（如
zerolog）输出service=api status=down error="timeout"，方便后续采集 - HTTP 健康端点返回 JSON，字段至少包含
status（overall）、services（各服务明细）、timestamp（采样时间），别只返回{"ok": true} - 如果上报 Prometheus，注意指标命名：用
service_health_status{service="auth", protocol="http"}，值为 0 或 1，别用字符串
复杂点在于多实例部署时的状态一致性——单机探测结果不能代表全局，得把各节点数据汇总到中心存储再计算。不过那是下一阶段的事了，先确保单机探测不漏、不卡、不死就行。
