本文介绍在 go 中实现应用高可用性的两种核心策略：一是通过 recover 捕获 panic 并局部恢复；二是借助外部监控或内部循环控制器（如 tideland/goas/loop）实现进程级自动重启，兼顾健壮性与可控性。
在构建 24 小时持续运行的 Go 后台服务（如 API 网关、数据采集器或定时任务调度器）时，单点崩溃会导致服务中断。Go 语言本身不提供类似 systemd 的进程守护或 Java 的 JVM 异常钩子机制，因此需主动设计容错与恢复逻辑。
✅ 方案一：内部 panic 恢复（轻量、响应快）
适用于因逻辑错误、空指针、切片越界等引发的 panic。Go 允许在 defer + recover 组合中拦截 panic，避免整个程序退出，并可选择性重启关键 goroutine：
func runWorker() {
defer func() {
if r := recover(); r != nil {
log.Printf("Worker panicked: %v, restarting in 1s...", r)
time.Sleep(time.Second)
go runWorker() // 递归重启
}
}()
// 实际业务逻辑（可能 panic）
processTask()
}⚠️ 注意：recover 仅在 defer 函数中有效，且只能捕获当前 goroutine 的 panic；它不能处理进程被 kill、OOM 或 runtime crash 等场景。
✅ 方案二：结构化循环控制（推荐生产使用）
更稳健的方式是将主业务封装为可管理的“可恢复协程”，借助成熟库（如 tideland/goas/loop）实现带重试策略的生命周期控制：
import "github.com/tideland/goas/loop"
func main() {
// 启动一个可恢复的 goroutine，支持 panic 后自动重启
loop.GoRecoverable(
func() { runServer() }, // 主逻辑
func(err interface{}) {
log.Printf("Server crashed: %v. Restarting...", err)
},
loop.WithMaxRestarts(5), // 5 分钟内最多重启 5 次
loop.WithRestartDelay(2*time.Second),
)
select {} // 阻塞主线程
}该方案优势显著：
- 支持重启次数限制与退避延迟，防止雪崩式反复崩溃；
- 可注入自定义恢复逻辑（如重连数据库、重载配置）；
- 与 loop.Stop() 配合，支持优雅关闭。
? 补充：外部进程监控（兜底方案）
当应用因 SIGKILL、内存溢出或死锁完全无响应时，建议辅以外部守护机制：
- Linux 下使用 systemd（配置 Restart=always, RestartSec=3）；
- Docker 中启用 --restart=unless-stopped；
- 自研心跳检测脚本（定期调用 /health 接口 + ps aux | grep myapp 进程检查）。
✅ 总结
| 场景 | 推荐方案 | 关键能力 |
|---|---|---|
| 协程级 panic | defer + recover | 快速恢复，低开销 |
| 服务级崩溃 | goas/loop.GoRecoverable | 可控重启、限频、可观测 |
| 系统级异常 | systemd / Docker / 自研 watchdog | 进程级兜底，脱离 Go 运行时 |
真正高可用的服务，从来不是“永不崩溃”，而是“崩溃后秒级自愈”。结合内部恢复与外部守护，才能让 Go 应用稳如磐石。
