Go微服务无法自身实现进程级自动重启，recover仅能拦截goroutine内panic，无法处理SIGKILL、OOM、死锁等真实故障；真正可靠的自动恢复需结合systemd进程兜底与loop库业务级韧性，并配以真实依赖感知的健康检查。
Go 微服务本身不具备自动重启能力，panic 不会触发进程重启，os.Exit() 只是退出——真正能实现“故障后自动恢复”的，必须靠外部守护或内部可控循环，而非单靠 recover。
为什么 recover 不能替代自动重启
recover 只在当前 goroutine 内有效，且仅对 panic 生效；它无法处理以下真实故障场景：
-
SIGKILL、OOM Killer杀死进程（无信号可捕获） - 死锁导致 goroutine 全部阻塞，main 退出
- cgo 调用崩溃、非法内存访问等 runtime crash
- 依赖服务长期不可用，业务逻辑卡在
select或time.Sleep中不响应
强行在每个 handler 或 worker 里套 defer recover，容易掩盖问题、积累状态泄漏，还可能让服务“假活”——HTTP 端口开着，但实际已无法处理请求。
生产环境该用 systemd 还是 loop 库
二者不是互斥选项，而是分工明确：
立即学习“go语言免费学习笔记（深入）”；
-
systemd负责进程级兜底：进程崩溃、OOM、被 kill 后自动拉起，配合RestartSec=5和StartLimitBurst=3防止重启风暴 -
tideland/goas/loop或自研循环控制器负责业务级韧性：把runServer()封装成可重启单元，支持失败计数、退避延迟、上下文重置，避免重启时复用旧连接或未关闭的资源
错误做法是只用 loop ——它救不了进程级崩溃；更错的是只靠 systemd ——它不管服务内部是否“心梗”，比如数据库连接池耗尽后一直返回 500，systemd 仍认为进程 healthy。
健康检查接口必须带依赖状态，不能写死 {“status”: “ok”}
Kubernetes 的 livenessProbe 或 Prometheus 的告警规则，都依赖这个接口的真实反馈。写死 OK 会导致：
- DB 连接断开，服务已不可用，但
kubectl get pods仍显示 Running - Redis 故障，缓存穿透压垮下游，健康检查却照常返回 200
- goroutine 泄漏导致内存持续上涨，但 /health 无感知
正确写法示例：
func healthHandler(w http.ResponseWriter, r *http.Request) {
dbOk := checkDBConnection()
redisOk := checkRedisPing()
if !dbOk || !redisOk {
w.WriteHeader(http.StatusInternalServerError)
json.NewEncoder(w).Encode(map[string]interface{}{
"status": "unhealthy",
"details": map[string]bool{"db": dbOk, "redis": redisOk},
})
return
}
w.WriteHeader(http.StatusOK)
json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
}
注意：这个接口要轻量、无副作用，不要在其中做重试或重建连接——那是恢复逻辑该干的事，不是探针该干的。
自动重启前必须做三件事：优雅关机、资源清理、状态隔离
否则重启只是把问题“复制粘贴”一遍：
- HTTP server 必须调用
srv.Shutdown(ctx)，等待活跃请求完成，不能直接srv.Close() - DB 连接池、Redis 客户端、gRPC 连接等需显式
Close()，否则新进程启动时可能因端口/文件句柄耗尽失败 - 避免多个副本同时触发重启：用分布式锁（如 Redis SETNX）或实例唯一标识控制，防止“全服抖动”
最容易被忽略的是临时状态残留——比如重启前没清空本地缓存文件、没释放 flock 锁、没重置指标计数器，会导致新进程一启动就继承旧错误状态。
