单纯在main函数加defer+recover无法兜住http handler或goroutine的panic，因recover仅对当前goroutine生效，跨协程panic必须各自显式捕获；recover不是熔断，需配合熔断器状态管理、失败计数及优雅shutdown。
单纯在 main 函数里加 defer + recover，根本兜不住 HTTP handler 或 goroutine 里的 panic——服务照样挂，连接照常堆积，熔断更是无从谈起。
recover 只对当前 goroutine 有效，跨协程 panic 必须各自捕获
很多人误以为在 main 里写个 defer func() { recover() }() 就能“全局兜底”，这是最典型的认知偏差。Go 的 recover 本质是协程级的中断恢复机制，它只对触发 panic 的那个 goroutine 生效。
- HTTP handler 是独立 goroutine，必须在 handler 内部或中间件里显式加
defer+recover - 用
go func() { ... }()启动的子任务，必须在该匿名函数开头就写defer func() { recover() }() - 第三方框架（如 Gin）的
gin.Recovery()本质就是把recover注入到每个 handler 执行链末尾，不是 magic 全局开关 - 如果漏掉某条路径（比如定时任务 goroutine、WebSocket 连接处理协程），一次 panic 就可能让整个服务不可用
recover 不等于熔断，它只是错误捕获的第一步
recover 的作用仅限于“不让程序崩”，但它不记录失败次数、不切换状态、不拒绝后续请求——这些才是熔断的核心。把 recover 和熔断混为一谈，等于把止血贴当成 ICU。
- 每次
recover捕获 panic 后，必须调用熔断器的MarkFailed()（如gobreaker）或hystrix.MarkFailed()，否则失败计数不会累积 - 熔断器状态（
Closed/Open/Half-Open）必须用sync/atomic或sync.RWMutex保护，否则并发下状态错乱会导致误判 - 请求入口处必须先调
breaker.Allow()，返回false就直接降级或返回429，不能等进到业务逻辑再 panic - 别用
hystrix-go的Do——它内部不recover，panic 会直接冒泡；改用DoC，它才做兜底并转成可判断的*hystrix.Error
panic 恢复后必须协同 Shutdown，否则资源泄漏比崩溃更危险
高频 panic 往往意味着服务已处于不稳定状态，硬扛只会让连接堆积、goroutine 泄漏、内存持续增长。此时真正的高可用动作是快速止损，而不是假装一切正常。
- 在
recover块里不要调os.Exit()，k8s 或 systemd 会判定为 crash，触发反复重启 - 应使用
sync.Once控制只触发一次srv.Shutdown()，停止接收新请求，同时等待活跃连接自然结束 - Shutdown 超时时间要合理（建议 10–30 秒），太短丢请求，太长拖慢滚动更新
- 降级逻辑本身必须零依赖：禁止在 fallback 里再发 HTTP/DB 请求，只能返回本地缓存或硬编码默认值；若需读 Redis，必须配独立限流和超时
真正难的不是写几行 recover，而是搞清每个 panic 发生在哪条执行路径、是否被正确捕获、失败是否被准确计入熔断器、状态变更是否线程安全、以及恢复后要不要关服务——这些细节全漏掉，防崩溃就只剩心理安慰。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
