健康检测用接口而非函数类型，因需支持依赖注入、mock测试及携带元信息；HTTP handler中须用context控制超时避免阻塞；应分层实现Liveness/Readiness/Startup检查；注册须延迟至main启动后防循环引用。
健康检测回调为什么要用接口而不是函数类型
因为 Go 的健康检测逻辑常需组合多个检查项（如数据库连通性、缓存可用性、外部服务响应），而不同模块的检测行为差异大，硬编码为 func() error 会导致扩展困难、无法注入依赖、难以 mock 测试。用接口能天然支持依赖注入和行为替换。
推荐定义统一接口：
type HealthChecker interface {
Check() error
Name() string // 用于日志和指标标识
}
不建议直接用 func() error 类型别名——它无法携带元信息，也无法在运行时区分是哪个模块触发的失败。
如何避免健康检测阻塞 HTTP handler
HTTP 健康端点（如 /healthz）必须低延迟、高可用，但某些检查（如 DB ping、第三方 API 调用）可能超时或卡死。不能让单个模块拖垮整个健康响应。
立即学习“go语言免费学习笔记（深入）”；
- 所有
Check()实现必须自带上下文控制：Check(ctx context.Context) error - 主 handler 中统一设置超时，例如
ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second) - 每个模块检查后应立即 select
ctx.Done()，不可忽略context.Canceled或context.DeadlineExceeded - 不要在
Check()内部启动 goroutine 后不等待——这会让超时失效
为什么需要分层聚合：Liveness vs Readiness vs Startup
Kubernetes 和云平台依赖三类信号，混用同一套回调会出问题。比如数据库连接失败应影响 readiness（暂停流量），但不应导致 liveness 重启进程（可能掩盖真实故障）。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
建议按语义拆分接口：
type LivenessChecker interface{ Check(context.Context) error }
type ReadinessChecker interface{ Check(context.Context) error }
type StartupChecker interface{ Check(context.Context) error }
实际注册时按需实现，例如：
- DB 模块只实现
ReadinessChecker和StartupChecker - 内存泄漏检测只实现
LivenessChecker - 配置热加载模块可能三者都不实现，只提供独立诊断 endpoint
回调注册时最容易被忽略的循环引用问题
当模块 A 的 HealthChecker 依赖模块 B 的实例，而模块 B 又在初始化时调用 A 的注册函数，就会触发 init 阶段死锁或 panic。
解决方法只有两个：
- 所有健康检查器注册必须延迟到
main()启动后，通过显式RegisterHealthChecker()函数，而非包级变量或 init 函数 - 避免在
Check()方法中直接调用其他模块的导出函数——改用接口传入，或通过依赖容器（如 fx、wire）注入 - 特别注意日志、metrics client 等基础组件：它们本身不该依赖业务模块健康状态，否则形成隐式环
最隐蔽的坑是：某个 Check() 里调用了 log.Printf，而日志库内部又尝试上报 metric，metric client 又去查配置中心……最终回到自己。
