应使用 systemd 或 supervisord 等外部进程管理器实现崩溃自动重启，配合应用内 panic 安全包裹、依赖服务降级重连机制，构建完整自恢复能力。
进程崩溃后如何自动重启
Go 程序本身不带守护能力，panic 未被捕获或发生段错误时会直接退出。靠 os.Exit() 或信号终止也不够可靠。真正落地的自恢复，得依赖外部进程管理器——不是自己写 for { exec.Command().Run() } 这类轮询重启逻辑（易失控、难监控、信号处理错乱）。
推荐用 systemd（Linux 生产环境事实标准）或 supervisord（轻量替代）。以 systemd 为例，关键配置项是：
-
Restart=always：任何退出都重启（含正常退出，慎用） -
RestartSec=5：失败后等 5 秒再试，避免夯住系统 -
StartLimitIntervalSec=60和StartLimitBurst=3：1 分钟内最多启动 3 次，超限则inactive (failed)，防止反复崩溃打满资源 -
KillMode=control-group：确保子进程（如 exec.Command 启的 shell、日志转发器）随主进程一并清理
别漏掉 StandardOutput=journal 和 StandardError=journal，否则崩溃日志进黑洞。
应用内 panic 捕获与安全退出
外部守护只能兜底进程级崩溃，但很多故障发生在业务逻辑中（比如数据库连接突然断开、HTTP handler panic）。这时要主动捕获，避免直接崩掉整个进程。
立即学习“go语言免费学习笔记（深入）”；
全局 recover 只对当前 goroutine 有效，且不能恢复已释放的栈。所以重点不是“捕获所有 panic”，而是“在关键入口处做防御性包裹”：
- HTTP server：用中间件包装
http.Handler，在ServeHTTP内 defer recover - goroutine 入口：所有
go func() { ... }()必须自带 recover，否则 panic 会静默消失 - 不要在 defer 中调用可能 panic 的函数（如
log.Fatal），否则二次 panic 会终止进程
示例（HTTP handler 安全包裹）：
func recoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
log.Printf("Panic recovered: %v", err)
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}()
next.ServeHTTP(w, r)
})
}
依赖服务不可用时的降级与重连
自恢复不是“重启就完事”，更要让服务在部分依赖失效时仍能响应（哪怕降级）。常见陷阱是：DB 连接池初始化失败 → main() 直接 panic → systemd 不停重启 → 日志刷屏。
正确做法是把依赖初始化拆成可重试、可超时、可降级的步骤：
- DB 初始化：用
sql.Open（不校验连接）+db.PingContext带 timeout 重试，失败不 panic，记录 warn 并启用内存缓存 fallback - Redis/消息队列：连接失败时先走本地
sync.Map缓存，后台 goroutine 持续重连，连上后再同步状态 - 第三方 API：加 circuit breaker（如
sony/gobreaker），连续失败后短路，返回预设 mock 数据
关键点：所有重试必须有指数退避（time.Sleep(time.Second ）和最大尝试次数，否则可能雪崩。
健康检查端点与 readiness/liveness 判断逻辑
Kubernetes 或 Consul 等平台依赖 /healthz 类端点做调度决策。但很多人只检查 “进程是否在跑”，这等于没检查。真正有用的健康检查必须反映业务就绪状态：
-
/livez：只检查进程存活（如能否响应 HTTP），对应 k8slivenessProbe。可只返回200，不查 DB -
/readyz：检查核心依赖（DB 连通性、配置加载完成、本地缓存 warmup 完成），对应 k8sreadinessProbe。任一失败就返回503 - 避免在
/readyz中执行耗时操作（如全表 count），用预计算的原子变量或 channel 通知机制更新就绪状态
容易被忽略的是：readinessProbe 失败时，k8s 会从 service endpoints 中摘除该实例；但如果应用没及时关闭监听 socket，旧连接仍可能被转发进来——务必在检测到依赖失联时，主动 srv.Shutdown() 正在处理的请求，并拒绝新连接。
