panic仅终止当前goroutine，主goroutine panic导致程序退出，子goroutine panic未recover则仅自身结束；recover必须在defer中调用且仅对同goroutine有效，返回interface{}需安全类型断言，http handler中recover后不可继续业务逻辑。
panic 会直接终止当前 goroutine，不是全局异常中断
Go 的 panic 不像 Java 或 Python 那样抛出可捕获的“异常对象”，它本质是运行时错误信号，只影响当前 goroutine。主 goroutine panic 会导致整个程序退出；子 goroutine panic 若未 recover，则该 goroutine 结束，但不会波及其他 goroutine —— 这点常被误认为“recover 能兜住所有错”。
实操建议：
- 别指望在 main 函数里 defer recover() 就能捕获所有 goroutine 的 panic —— 它只对当前 goroutine 有效
- 每个可能 panic 的 goroutine（尤其是
go func() { ... }()）都得自己配defer recover() - log.Fatal、os.Exit 等显式退出不会触发 defer，也绕过 recover，它们比 panic 更“硬”
recover 必须在 defer 中调用，且必须在 panic 发生后的同一 goroutine 中
recover 不是函数调用就能生效的“开关”，它只有在 defer 函数执行期间、且当前 goroutine 正处于 panic 过程中，才会返回非 nil 值。一旦 panic 已结束（比如被上层 recover 拦截后），再调用 recover() 永远返回 nil。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 把
recover()放在普通函数里（没 defer），永远拿不到 panic 值 - 在 defer 函数里加了条件判断却忘了：
if r := recover(); r != nil { ... }必须写成一行或确保不被提前 return 中断 - 误以为 recover 后程序能“继续执行 panic 那行之后的代码”——实际 panic 后的代码根本不会执行，recover 只是让 goroutine 有机会清理并退出
recover 拿到的是 interface{}，类型断言失败是静默的坑
recover() 返回 interface{}，多数 panic 是由 panic("xxx") 或 panic(err) 触发，但你不能默认它是 string 或 error。直接强制转 err.(error) 可能 panic（类型不匹配），而 err.(string) 在传入 struct 时直接 panic。
安全做法：
- 总是用带 ok 的类型断言：
if s, ok := r.(string); ok { ... } - 优先检查是否实现了 error 接口：
if err, ok := r.(error); ok { ... } - 兜底打印原始值：
fmt.Printf("panic value: %+v (type: %T)", r, r) - 别用
fmt.Sprintf("%v", r)直接拼日志——如果 r 是自定义 panic 类型且 String() 方法又 panic，会二次崩溃
HTTP handler 中 recover 不能替代中间件设计，且需防 panic 嵌套
Web 服务里常见在 http.HandleFunc 内写 defer recover()，但这只是底线防护。真实问题在于：recover 后 HTTP 连接可能已半关闭，responseWriter 可能不可写，http.Error(w, ...) 可能 panic。
关键细节：
- 必须在 defer 里检查
w.Header().Get("Content-Type") == ""才能安全写 response，否则可能已写过 header - 不要在 recover 后继续业务逻辑（比如重试 DB 查询）——goroutine 状态已不可信
- 如果 handler 内部调用了另一个可能 panic 的函数，而那个函数自己也 recover 了，外层 recover 拿不到 panic 值 —— panic 被“吃掉”了，日志里只剩沉默
- 标准库
http.Server的ErrorLog默认不记录 panic，要自己 hookRecover并打日志
