recover() 直接调用恒返回 nil，必须置于 defer 函数体内且 defer 需在 panic 前注册；仅对本 goroutine 有效；recover 后不可继续原逻辑，须清理资源并退出。
recover() 直接调用永远返回 nil
这是最常被忽略的前提：在函数体任何位置（包括 panic() 后面）直接写 recover()，它都只是个普通函数调用，返回值恒为 nil。Go 运行时根本不会把它和当前 panic 关联起来。
原因在于 recover 不是“监听器”，它依赖运行时在 panic 堆栈解退过程中、执行 defer 函数时的特殊上下文。脱离这个上下文，recover 就失去了唯一能识别 panic 的能力。
- 错误写法：
func bad() { panic("x"); r := recover() }——r一定是nil - 正确前提：必须把
recover()放进defer注册的函数体内部 - 哪怕只差一层包装，比如
defer func() { runRecover() }()，其中runRecover是个独立函数，也会失效
defer 必须在 panic 发生前注册
defer 语句本身是立即执行的（注册动作），但 deferred 函数体要等到函数返回时才执行。所以，如果 defer 写在 panic() 后面，它根本没机会注册，自然也捕获不到。
常见于条件分支或 late-init 场景：比如只在某个 if 分支里写 defer，而 panic 发生在另一个分支，或者发生在 defer 之前就已 return。
- 必须把
defer放在可能触发 panic 的逻辑之前，越早越好 - 推荐统一放在函数开头，避免遗漏路径
- 多个
defer按后进先出执行，recover应该放在最靠近 panic 可能点的那个defer中（通常就是第一个）
recover 只对本 goroutine 的 panic 有效
主 goroutine 的 defer + recover 对子 goroutine 的 panic 完全无感。这不是 bug，是 Go 并发模型的设计原则：每个 goroutine 独立拥有自己的 panic/recover 作用域。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误场景：HTTP handler 启动子 goroutine 处理耗时任务，子 goroutine panic，主线程毫无反应，连接却断了；或者用 go func() { ... panic() }() 启动，外面套个 defer recover()，结果照样崩溃。
- 每个可能 panic 的 goroutine 都得自己配
defer func() { if r := recover(); r != nil { ... } }() - 不要指望“父级兜底”，必须“谁启动、谁防护”
- 可封装一个安全启动器：
safeGo(func() { ... })，内部自动加 defer+recover
recover 后不能继续原逻辑，状态可能已损坏
recover() 的作用仅是终止 panic 传播、让 goroutine 恢复调度，它**不会回滚任何副作用**，也不会让程序回到 panic 那一行继续执行。
比如 panic 前已 close channel、已写入文件、已修改全局变量，这些操作不可逆。若在 recover 后继续用这些资源，大概率触发二次 panic 或数据错乱。
- recover 后应立即做三件事：记录 panic 值（
fmt.Sprint(r)）、清理关键资源（如关闭打开的文件或连接）、返回或退出 - 避免类型断言失败导致二次 panic：用
switch r.(type)或直接fmt.Sprintf("%v", r)打日志 - 尤其注意：recover 不等于“错误处理”，它只适用于防止整个 goroutine 崩溃，业务错误仍该用
error显式传递
真正难的不是写对语法，而是判断哪里该加、加在哪一层、加完之后敢不敢信任那个“恢复”后的状态。多数线上事故，不是没加 recover，而是加了却误以为万事大吉，接着用坏掉的资源往下跑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
