go服务应暴露/health端点，检查进程状态与关键依赖（如DB、redis），返回200或503；需结合资源水位（如内存）与关键路径探活，避免仅依赖http 200；同时集成prometheus指标和panic防护机制。
Go 服务如何暴露健康检查端点（/health）
生产环境必须提供可被外部探测的健康状态接口，最常用的是 HTTP /health 端点。它不返回业务数据，只反映进程是否存活、关键依赖是否就绪。
用标准库即可实现，无需额外框架：
func healthHandler(w http.ResponseWriter, r *http.Request) { // 检查本地状态：goroutine 数量、内存压力等（可选） // 检查关键依赖：数据库 ping、redis 连接、下游 HTTP 服务连通性 if err := db.Ping(); err != nil { http.Error(w, "db unreachable", http.StatusServiceUnavailable) return } if err := redisClient.Ping(r.Context()).Err(); err != nil { http.Error(w, "redis unreachable", http.StatusServiceUnavailable) return } w.WriteHeader(http.StatusOK) w.Write([]byte("ok")) }注意：http.StatusServiceUnavailable（503）比 500 更准确，表示“暂时不可用”，适合监控系统自动降级或剔除流量。
为什么不能只靠 HTTP 200 判断服务正常
HTTP 200 只代表 handler 执行完没 panic，并不等于业务可用。常见陷阱包括：
立即学习“go语言免费学习笔记（深入）”；
-
db.Ping()成功但慢查询堆积，连接池耗尽 - Redis 连接正常，但
SET命令超时或返回MOVED重定向错误 - 依赖的 gRPC 服务响应 200，但实际返回了
status.Code == codes.Unavailable - 内存持续上涨，
runtime.ReadMemStats()显示HeapInuse接近上限
所以健康检查逻辑里必须包含「关键路径探活」+「资源水位快照」，例如：
var memStats runtime.MemStats runtime.ReadMemStats(&memStats) if memStats.HeapInuse > uint64(800*1024*1024) { // 超 800MB http.Error(w, "high memory usage", http.StatusServiceUnavailable) return }如何用 Prometheus + /metrics 暴露运行时指标
Prometheus 是 Go 服务最主流的指标采集方案，需引入 prometheus/client_golang 并注册指标：
import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp" ) var ( httpRequestsTotal = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "http_requests_total", Help: "Total number of HTTP requests", }, []string{"method", "status"}, ) ) func init() { prometheus.MustRegister(httpRequestsTotal) } // 在 HTTP handler 中记录 httpRequestsTotal.WithLabelValues(r.Method, strconv.Itoa(statusCode)).Inc()然后挂载 /metrics handler：
http.Handle("/metrics", promhttp.Handler())关键点：promhttp.Handler() 默认只暴露 Go 运行时指标（goroutines、GC 次数等），业务指标需显式 MustRegister()；且避免在请求中高频调用 WithLabelValues() 创建新指标实例，应复用。
进程级异常：如何捕获 panic 并上报
HTTP server 启动后发生的 panic（如 handler 内未处理的空指针）会导致整个服务退出。必须做两层防护：
- 全局
http.Server的ErrorLog配置，捕获底层监听错误 - 每个 handler 内用
defer/recover捕获 panic，并记录结构化日志
示例：
func safeHandler(fn http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { defer func() { if err := recover(); err != nil { log.Printf("PANIC in %s %s: %v", r.Method, r.URL.Path, err) // 上报到 Sentry / Datadog / 自建告警通道 reportPanic(err, r) http.Error(w, "Internal Server Error", http.StatusInternalServerError) } }() fn(w, r) } } http.HandleFunc("/api/user", safeHandler(userHandler))注意：recover() 只对当前 goroutine 有效，无法捕获其他 goroutine（如定时任务、消息消费协程）的 panic，这些需单独加 defer/recover。
真正难的是依赖链路的异步失败——比如一个 HTTP 请求触发了 kafka 消息发送，而发送 goroutine panic 了，主请求却已返回 200。这种场景必须靠 end-to-end trace + 异步任务状态表 + 定期巡检来兜底。