Iris 框架需手动实现健康检查，因其无 Spring Boot 的 HealthIndicator 等抽象层；应注册 /health 路由返回结构化 JSON，状态码准确、依赖检查须异步或超时，K8s 探针需区分 liveness/ready 端点。
Iris 框架本身不内置健康检查端点，必须手动实现；直接复用 Spring Boot Actuator 那套思路会失败，因为 Iris 没有 HealthIndicator 接口或自动装配机制。
为什么不能照搬 Spring Boot 的健康检查逻辑
Iris 是 Go 语言框架，没有 Java 生态里的 Actuator、HealthIndicator、@Endpoint 等抽象层。所谓“开启健康检查”在 Iris 里就是写一个普通 HTTP handler，返回 JSON 并自行定义检查逻辑。常见误区是试图配置 eureka.client.healthcheck.enabled=true —— 这属于 Spring Cloud 客户端配置，对 Iris 完全无效。
- Spring 的健康检查依赖 JVM 生命周期和 Bean 扫描，Iris 没有 Bean 容器
-
/actuator/health是 Spring 特定路径，Iris 默认连这个路由都没有 - 第三方库如
go-health或uber-go/zap的 health 包可集成，但需手动挂载，不是开箱即用
最简可行的健康检查 handler 实现
用原生 Iris 路由注册一个 GET /health，返回结构化 JSON 即可。关键点在于：状态码要准确、字段语义清晰、避免阻塞主线程。
- 返回
200 OK表示服务可接受请求，不是“所有依赖都正常” - 数据库、Redis、外部 API 等依赖项检查应异步或加超时，否则拖慢整个健康接口
- 不要在
/health里做耗时操作（如查表、发 HTTP 请求），除非明确需要“深度探活” - 示例代码：
app.Get("/health", func(ctx iris.Context) {
// 快速检查：进程存活、路由可用
health := map[string]interface{}{
"status": "UP",
"uptime": time.Since(startTime).String(),
"version": "v1.2.0",
}
<pre class="brush:php;toolbar:false;">// 可选：轻量级依赖检查（带超时）
if err := pingDBWithTimeout(500 * time.Millisecond); err != nil {
health["db"] = "DOWN"
health["status"] = "DEGRADED" // 不直接设为 DOWN，避免误杀
} else {
health["db"] = "UP"
}
ctx.JSON(health)})
对接 Kubernetes liveness/readiness probe 的注意事项
K8s 的探针依赖 HTTP 状态码和响应内容，但默认配置容易踩坑：
-
livenessProbe失败会重启 Pod，所以/health里不要包含可能短暂失败的检查（如临时网络抖动导致的 Redis ping 超时） -
readinessProbe应更严格，比如要求 DB 和核心缓存都就绪才返回 200 - K8s 默认只看 HTTP 状态码，
status: "DOWN"字段不会触发重启 —— 必须靠 status code 控制 - 建议拆成两个端点：
/health/live（只检查进程和监听端口）、/health/ready（检查 DB、Redis、配置加载等）
进阶：用中间件统一注入健康上下文
如果多个服务共用一套健康逻辑（如共享 DB 连接池、配置中心客户端），可以把检查封装成可复用函数，再通过中间件注入到 handler 中：
- 定义一个
HealthChecker接口，含Check() error方法 - 把具体实现（如
DBHealthChecker、ConfigHealthChecker）注册进全局 map - 在
/health/readyhandler 中遍历执行，聚合结果 - 注意：每个
Check()必须自带超时控制，避免单个失败拖垮整体响应
真正容易被忽略的是——健康检查接口本身也是服务的一部分，它占用 Goroutine、内存和连接资源。线上压测时，高频调用 /health 可能成为瓶颈，尤其当它内部做了同步 HTTP 调用或锁操作。别只盯着业务接口优化。
