第三方库 panic 无法被外层 defer 捕获，必须在调用点同一 goroutine 内立即注册 defer + recover()；子 goroutine 需各自防护；recover 后应清理资源并退出，配合 debug.Stack() 打印完整堆栈。
第三方库 panic 无法被外层 defer 捕获
直接在调用第三方库函数的外层加 defer func() { recover() }() 是无效的——只要那个库函数没在当前 goroutine 内 panic，或者 panic 发生在它启动的子 goroutine 里，recover() 就永远返回 nil。常见现象是：日志里看不到 panic 记录，程序却突然退出，或某个 HTTP handler 静默失败。
必须在调用点同一 goroutine 内注册 defer
第三方库代码你无法修改，但你可以控制它的执行上下文。防护的关键是：确保 recover() 和 panic 发生在同一个 goroutine、且 defer 在 panic 前已注册。
- 把库调用包进一个匿名函数，并在其内部立即注册
defer func() { if r := recover(); r != nil { /* 处理 */ } }() - 不要写成
defer recover()或defer handleRecover()，后者会让recover()在注册时就执行，此时还没 panic - 如果库函数本身会起 goroutine（比如某些异步 SDK、数据库驱动的回调钩子），那这些子 goroutine 必须各自配
defer+recover()，外层无能为力
recover 后别复用可能已损坏的状态
第三方库 panic 的原因往往是越界、空指针、并发写 map 等——recover() 能拦住崩溃，但不修复内存或数据结构。紧接着访问刚 panic 过的 slice、map 或未关闭的 file，大概率二次 panic。
- recover 后优先做资源清理：显式调用
file.Close()、conn.Close()、mu.Unlock() - 避免继续传参给其他函数，尤其是那些依赖该库返回值状态的逻辑
- 推荐模式：
if r := recover(); r != nil { log.Printf("panic in lib: %v", r); return }，记录完就退出当前函数
打印堆栈必须用 debug.Stack()，且得在 recover() 后立刻调用
recover() 只返回 panic 值（比如 "index out of range"），不带位置信息。要定位到底哪一行触发了第三方库的 panic，必须配合 runtime/debug.Stack()。
- 调用顺序不能错：先
r := recover()，再debug.Stack()；如果中间夹了其他 defer 或函数调用，栈可能被污染 -
debug.Stack()返回[]byte，记得转成string()才能打印或写日志 - 生产环境建议截断长度，例如
stack := debug.Stack(); if len(stack) > 4096 { stack = stack[:4096] }
最易被忽略的是：第三方库的 panic 往往藏在回调、hook、或初始化阶段，不是简单包一层 defer 就能兜住。真正可靠的防护，是把它当成“不可信边界”，每个调用点都独立设防，而不是指望某个全局 wrapper。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
