recover必须在defer中调用才能捕获panic值，否则返回nil；子goroutine需自行recover；应使用debug.Stack()获取完整调用栈；recover后仅做安全清理并退出。
recover 必须在 defer 中调用，否则永远拿不到 panic 值
这是最常踩的坑：把 recover() 写在普通函数体里、if 分支中，或者 panic 之后但没包在 defer 里——它一定返回 nil。Go 运行时只在 panic 正在传播、且当前 goroutine 的 defer 链正在执行时，才把 panic 值“塞”给 recover()。
-
recover()是“被动接收”，不是“主动监听”，离开 defer 上下文就失效 - 匿名函数里写
defer func() { recover() }()是对的；写成defer recover()是错的（会立即执行，不是延迟） - 如果 defer 函数里有提前 return 或 panic，
recover()可能根本没机会执行
goroutine 内 panic 必须自己 recover，主 goroutine 捕不到
子 goroutine 发生 panic，主 goroutine 完全无感——它不会传播，也不会终止进程（除非只剩这一个 goroutine）。但静默退出极危险：文件没关闭、数据库连接泄漏、定时任务停摆，日志里还什么都没有。
- 错误写法：
go riskyFunc()然后在 main 里 defer recover —— 完全无效 - 正确写法：每个
go启动时立刻包一层带defer+recover()的闭包 - 推荐封装：
goSafe(func() { ... })，内部自动注入 recover 和debug.Stack()
别只打印 panic 字符串，必须用 debug.Stack() 拿完整调用栈
仅记录 recover() 返回的值（比如 "index out of range"）等于白抓——你不知道在哪一行、哪个函数、什么参数下崩的。真正有用的现场信息藏在栈里。
-
debug.PrintStack()直接输出到 stderr，难统一收集；必须用debug.Stack()返回[]byte，才能写进结构化日志字段 - 不要用
runtime.Stack(buf, false)省事：它默认只取前 4096 字节，长栈会被截断；建议用debug.Stack()，它自动扩容 - panic 值类型不确定，别直接断言
error：r := recover(); if err, ok := r.(error)更安全
recover 后不能“继续跑业务逻辑”，只能清理并退出
recover 不是重试开关，它只是让 goroutine 从 panic 状态“软着陆”。一旦 recover 成功，程序会跳过 panic 后所有代码，直接执行 defer 后面的语句，然后函数返回。
立即学习“go语言免费学习笔记（深入）”；
- 常见误操作：recover 后接着调用
doSomethingElse()—— 如果状态已损坏（如 map 被置 nil、锁未释放），这步大概率再 panic - 安全做法：recover 后只做确定安全的事——关文件、释放锁、发告警、写日志，然后 return 或 os.Exit(1)
- HTTP handler 是典型场景：recover 后
http.Error(w, "...", 500)并记录，绝不能试图“补救”后继续写响应
