defer+recover 必须在每个 http handler 和 goroutine 内部显式添加，因 panic 不跨 goroutine 传播；recover 仅止血，需同步记录日志、上报指标、调用熔断器、安全降级并协同 shutdown。
单纯在 main 函数加 defer+recover 完全无效，HTTP handler 和 goroutine 的 panic 依然会直接导致服务不可用。
HTTP handler 必须每个都包 recover
Go 的 HTTP server 启动每个请求都在独立 goroutine 中执行，main 函数里的 recover 对它完全不生效。Gin 的 gin.Recovery()、Echo 的 middleware.Recover() 之所以“管用”，是因为它们把 defer func() { recover() }() 插入到了每个 handler 的执行链最外层。
- 自己写 HTTP server 时，必须在每个 handler 函数开头手动加
defer func() { if r := recover(); r != nil { /* 记录日志、上报指标 */ } }() - 如果用了中间件，确保它被注册在所有路由之前；漏掉一个路由（比如健康检查 /health 或 WebSocket 升级路径），一次 panic 就可能让整个连接池卡死
- recover 后不能继续用已损坏状态：比如 panic 发生在 DB transaction 中间，recover 后没调
tx.Rollback()，下次复用该连接就会报sql: transaction has already been committed or rolled back
后台 goroutine 必须各自显式捕获
任何用 go func() { ... }() 启动的子任务，panic 都不会传播到主 goroutine，也不会被其他地方的 recover 捕获——它只会静默终止，伴随 goroutine 泄漏和资源未释放。
- 定时任务：
go func() { defer func() { if r := recover(); r != nil { log.Printf("cron panic: %v", r) } }(); runJob() }() - WebSocket 连接处理：
go func(conn *websocket.Conn) { defer func() { if r := recover(); r != nil { log.Printf("ws conn %p panic: %v", conn, r) conn.Close() } }(); handleConn(conn) }(c) - 异步日志/监控上报协程：同样要包，否则 panic 后日志停发、指标断更，你根本不知道服务已经半瘫痪
recover 不是熔断，漏掉这三步等于白加
recover 只负责“止血”，不记录失败、不切换状态、不拒绝后续请求。把它当成熔断器，就像用创可贴治心梗。
- 每次
recover()捕获后，必须同步调用熔断器的MarkFailed()（如gobreaker.NewCircuitBreaker()的实例） - 入口处必须先调
breaker.Allow()，返回 false 就立即返回 429 或降级响应，绝不能放行进业务逻辑再等 panic - 状态变量（如
state字段）必须用sync/atomic或sync.RWMutex保护，否则并发下Closed → Open状态跃迁可能丢失，导致雪崩
recover 后必须协同 Shutdown，不能硬扛
高频 panic 往往是服务已处于资源耗尽或逻辑错乱状态，强行恢复并继续提供服务，只会加剧连接堆积、goroutine 泄漏、内存持续上涨。
- recover 块里禁止调
os.Exit()，k8s 会判定为 crashloop，反复拉起新 Pod - 应使用
sync.Once控制只触发一次srv.Shutdown()，停止接收新请求，同时给活跃连接留出自然结束时间 -
Shutdown超时建议设为 10–30 秒：太短丢请求，太长拖慢滚动更新；超时后强制srv.Close() - 降级逻辑本身必须零依赖——不能再去调下游、不能写 DB、不能发 MQ，否则可能引发二次 panic
真正容易被忽略的是：recover 捕获后，你拿到的只是 panic 值，但调用栈、goroutine ID、当前 request ID 全都丢了。不立刻用 debug.Stack() 记录完整上下文，下次排查就是盲人摸象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
