recover仅作用于当前goroutine，必须与defer配合在panic发生时捕获；http handler、子goroutine等需各自显式添加recover，否则进程仍会崩溃，且recover后状态未知，不可盲目继续执行。
recover 不能防止程序崩溃退出，它只能防止当前 goroutine 崩溃退出；漏掉任意一个 goroutine 的 recover，整个进程仍可能因 panic 而终止。
recover 必须和 defer 一起用，且只能在 defer 函数里调
在普通函数体中直接写 recover() 永远返回 nil，完全无效。它只在 defer 执行期间、且当前 goroutine 正处于 panic 状态时才有意义。
- defer 语句必须写在可能触发 panic 的代码之前，否则 panic 发生后 defer 根本不会注册
- recover 返回值是
interface{}类型：有 panic 时返回传给panic()的值（比如"division by zero"），没 panic 时返回nil - recover 成功后，panic 被“吃掉”，但触发 panic 的那行之后的代码不会执行，函数会从 defer 块之后继续返回
HTTP handler 里不加 recover，单个请求 panic 就会让整个服务不可用
Go 的 http.ServeMux 或框架（如 Gin、Echo）默认对每个请求启动独立 goroutine。main 函数里的 defer+recover 对它们完全无效。
- 必须在每个 handler 函数开头或中间件里显式加
defer func() { if r := recover(); r != nil { /* 记录日志 + http.Error */ } }() - Gin 的
gin.Recovery()本质就是把这段逻辑注入到 handler 执行链末端，不是 magic 全局开关 - 如果用了自定义路由、WebSocket 连接处理、长轮询协程，每种路径都要单独加 recover
子 goroutine 的 panic 必须各自捕获，main 里加 defer 没用
Go 的 recover 是 goroutine 局部的。用 go func() { ... }() 启的协程，panic 只影响自己，但没人 recover 的话，该 goroutine 会静默退出——可能造成资源泄漏、状态不一致，甚至因堆积导致 OOM。
- 所有显式启动的 goroutine，第一行就该是
defer func() { recover() }() - 不要依赖外部“统一兜底”：
runtime.Gosched()或sync.WaitGroup都不能替代每个 goroutine 内部的 recover - recover 后建议打日志（带
runtime/debug.Stack()），否则 panic 无声消失，问题极难定位
recover 不是 error 处理替代品，滥用会导致状态错乱
recover 解决的是“程序不该崩”，不是“业务逻辑该怎么走”。它无法回滚已发生的副作用（比如数据库写入、文件修改、channel 发送）。
- 除零、空指针解引用、切片越界等 panic，应优先用常规
if判断规避，而不是靠 recover 补救 - recover 捕获后，不要简单忽略错误并继续执行；需明确是否降级、返回默认值、或主动关闭连接
- 高频 panic 往往意味着服务已不稳定，此时更关键的是快速
srv.Shutdown()，而非硬扛
最常被忽略的一点：recover 后的程序状态大概率是未知的。你不知道 panic 前一刻变量是否已被部分修改、channel 是否已发送、锁是否还持有——它只是让代码“没退出”，不代表“还能用”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
