panic 不会跨 goroutine 传播，必须在每个可能 panic 的 goroutine 内部用 defer+recover 捕获；recover 仅在 defer 函数中直接调用有效；recover 后须清理资源防泄漏；goroutine 中禁用 log.fatal/os.exit。
panic 不会跨 goroutine 传播
Go 的 panic 只在当前 goroutine 内崩溃，不会“冒泡”到启动它的父 goroutine 或其他 goroutine。这是设计使然，不是 bug —— 否则一个子协程出错就 kill 掉整个程序，根本没法做健壮的并发服务。
常见错误现象：recover 在主 goroutine 里写得再全，也抓不到子 goroutine 里的 panic；日志里只看到 panic: xxx 加一堆 goroutine stack，但程序没退出、也没触发你写的 recover 逻辑。
- 必须在每个可能 panic 的 goroutine 内部单独用
defer+recover - 不要指望在
go func() { ... }()外面包一层defer/recover—— 它俩不在同一个执行流里 - 如果 goroutine 是通过第三方库启动（比如
http.Server启的 handler），得确认它是否已内置 recover，否则你的 panic 会直接打印到 stderr 并丢失上下文
recover 必须紧挨 defer 才有效
recover 只有在 defer 函数中调用才起作用，而且不能被包裹在更深的函数调用里（比如传给闭包、或者放在 if 分支里但分支没执行）。
使用场景：处理网络请求时，避免单个请求 panic 导致整个 HTTP server 挂掉。
立即学习“go语言免费学习笔记（深入）”；
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("request panicked: %v", r)
}
}()
// 这里可能 panic，比如 map 写 nil、索引越界
processRequest()
}()
- 写成
defer recover()是无效的 ——recover立即执行，此时还没 panic - 写成
defer func() { recover() }()也不行 —— 没接返回值，等于白写 - 如果
recover被包在if err != nil { recover() }里，而 panic 发生时 err 是 nil，那就彻底漏抓
goroutine 泄漏比 panic 更隐蔽
很多人专注 catch panic，却忽略 recover 后的资源清理。比如 goroutine 里开了 timer、占了 channel、持有了 mutex，recover 之后没关、没释放、没 close，这个 goroutine 就永远卡住，变成泄漏。
性能影响：泄漏的 goroutine 不会自动 GC，堆栈内存持续占用，runtime.NumGoroutine() 持续上涨，最终 OOM。
- recover 后务必检查：channel 是否该 close、timer 是否该 stop、锁是否该 unlock、文件/连接是否该 close
- 别在 defer 里只写
recover()，后面跟上 cleanup 逻辑，或用命名返回值封装清理行为 - 用
pprof/goroutines定期看 goroutine 堆栈，重点查select {}、chan receive、semacquire卡住的长期存活 goroutine
log.Fatal 和 os.Exit 在 goroutine 里会杀整个进程
这不是 panic，但效果更猛：只要任意 goroutine 执行 log.Fatal 或 os.Exit，整个进程立刻终止，连 main 函数的 defer 都不执行。
容易踩的坑：把调试用的 log.Fatal("debug") 误留在生产代码的 goroutine 中；或第三方库内部调用了 os.Exit（比如某些 CLI 工具库）。
- 永远不要在 goroutine 里用
log.Fatal、os.Exit、panic（除非你明确要终结进程） - 替代方案：返回 error、发信号到控制 channel、调用自定义的 shutdown hook
- CI 阶段可用静态检查工具（如
staticcheck）配规则SA1017检出 goroutine 中的os.Exit
真正难的不是写 recover，而是判断该不该 recover、recover 之后该不该继续跑、以及怎么让失败的 goroutine 彻底退场而不是变成僵尸。很多线上事故，根子不在 panic 本身，而在 recover 后忘了关连接、忘了通知上游、忘了更新状态。
