recover必须在defer中调用才有效，且仅捕获同goroutine的panic；init中的panic无法被main的recover捕获；启动阶段panic应记录后os.Exit(1)。
recover 必须在 defer 中调用才有效
Go 的 recover 只能在 defer 函数中捕获当前 goroutine 的 panic，且仅对同一 goroutine 生效。服务启动时若主 goroutine panic（比如初始化数据库失败、监听端口被占用），不加 defer 的 recover 完全不起作用。
常见错误是把 recover 写在普通函数里，或者放在 main 函数开头——这毫无意义，panic 发生时它早已执行完毕。
-
defer func() { if r := recover(); r != nil { log.Fatal("startup panic:", r) } }()是最简可行写法 - 必须紧贴可能 panic 的代码之前（如
http.ListenAndServe前），否则 panic 已经终止程序 - 不能跨 goroutine：子 goroutine 中 panic 需各自
defer+recover，主 goroutine 的recover看不见
只 recover 启动阶段 panic，别包住整个 http.Serve
很多新手把 http.ListenAndServe 整个包进 defer + recover，以为能“兜住服务崩溃”。这是错的：http.Serve 本身不 panic（出错返回 error），真正 panic 通常发生在 handler 内部，而 handler 是在新 goroutine 执行的。
启动异常特指：配置解析失败、依赖组件（DB/Redis）初始化 panic、证书加载失败、net.Listen 失败后手动 panic 等——这些都在 main 或 init 阶段发生。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：在所有初始化逻辑之后、
http.ListenAndServe之前放defer recover - 错误做法：
go func() { defer recover(); http.ListenAndServe(...) }()—— recover 在子 goroutine 里，但 panic 若发生在主线程，它根本捕不到 - 如果真想处理运行时 handler panic，要用
http.Server.ErrorLog配合中间件级 recover（另起 goroutine 捕获）
recover 到 panic 后该立刻退出，别尝试“恢复服务”
启动阶段 panic 意味着程序处于不可预期状态：内存可能已损坏、全局变量未初始化、依赖连接半开。此时 recover 的唯一合理动作是记录错误并退出进程，而不是重试或继续启动。
常见反模式是 recover 后 sleep 几秒再重 exec 自身，或跳过失败模块硬启服务——这会让问题更隐蔽，日志里只剩“started”，实际功能缺失。
- recover 后必须调用
os.Exit(1)（或log.Fatal），避免后续代码执行 - 不要只打印日志就 return：main 函数 return 仍会继续执行后续语句，panic 上下文已丢失
- 若需区分 panic 类型（如配置错误 vs 系统资源不足），可断言
r是否为error或自定义 error 类型，但退出动作不变
注意 init 函数中的 panic 无法被 main 里的 recover 捕获
Go 的 init 函数在包加载时自动执行，早于 main。如果某个依赖包（比如 database/sql 驱动注册时）或你自己写的 init 里 panic，main 函数甚至没机会运行，自然也来不及设 defer。
这种 panic 表现为程序直接 crash，stderr 输出类似 panic: failed to initialize DB，无任何自定义日志。
- 排查方式：用
go build -gcflags="-m" .看初始化顺序，或在关键init里加log.Println("in init") - 解决方案：把易 panic 的逻辑从
init移到main或显式初始化函数中，由你控制 defer/recover - 第三方包 init panic 属于其 bug，只能降级版本或换库；无法用 recover 补救
