recover只能捕获当前goroutine的panic，且必须在panic前注册defer、在defer函数体内直接调用；跨goroutine无效，recover后不可继续业务逻辑，panic非error替代品。
recover 不能捕获其他 goroutine 的 panic，也不能在 defer 外调用——这两点没搞清，90% 的 recover 代码都白写了。
recover 必须写在 defer 函数体内，且 defer 要在 panic 前注册
很多人写成 panic("x"); defer func() { recover() }()，这根本捕获不到。因为 defer 是在 panic 之后才注册的，而 panic 会立刻展开栈、执行已注册的 defer，但此时这个 defer 还没注册上。
-
defer语句必须出现在panic之前，才能确保它被纳入当前 goroutine 的 defer 链 -
recover()必须是 defer 匿名函数体内的**直接调用**，不能包在另一层函数里（比如go func() { recover() }()） - 错误示例：
func f() { panic("boom"); r := recover() }——recover()根本不会执行 - 正确写法：
func f() { defer func() { if r := recover(); r != nil { log.Print(r) } }(); panic("boom") }
panic/recover 是 goroutine 局部机制，无法跨协程传播或捕获
主线程里写了 defer + recover，对 go func() { panic("x") }() 完全无效。子 goroutine 崩溃后静默退出，主 goroutine 不知情。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 每个 goroutine 有独立的 panic/recover 作用域，
recover只能捕获**当前 goroutine 正在传播中的 panic** - HTTP handler 中起 goroutine 处理耗时任务，里面 panic → handler 不会触发 recover → 日志无声丢失
- 解决方案不是在外层加 recover，而是每个 worker 内部自己加：
go func() { defer func() { recover() }(); doWork() }() - 封装
safeGo时，必须确保传入的函数内部也带 recover，否则只是把崩溃从显式变成隐蔽
recover 后不能继续业务逻辑，只适合清理、降级或记录
recover() 成功后，程序不会回到 panic 那一行重试，而是从 defer 函数返回后继续执行后续语句。此时局部状态大概率已损坏。
- 数组越界后，
arr[x] = 88已失败，但arr可能部分初始化、指针可能已解引用失败 - 不要在 recover 分支里调用依赖该状态的业务代码（如再次写 DB、发 HTTP 请求）
- 合理做法：记录 panic 堆栈 + request ID → 返回 500 或 fallback 响应 → 显式
return或os.Exit(1) -
recover()不回滚任何副作用，它不是事务机制，只是提供一次“软着陆”机会
panic 不是 error 替代品，仅用于真正不可恢复的错误
把 os.Open 失败、HTTP 请求超时、数据库查不到记录这些常规错误用 panic 处理，会导致测试难、监控失真、错误不可控。
- 推荐场景：
init阶段配置加载失败、断言失败（x.(T)）、空指针解引用、向已关闭 channel 发送数据 - 业务错误一律用
error返回，配合多值返回和if err != nil判断 - 滥用
panic会让单元测试难以 mock 和覆盖，也会让 Prometheus 指标中 panic 次数失真 - Web server 中 recover 常见用途：防止单个 HTTP handler panic 导致整个服务退出，但仅限兜底，不替代 proper error handling
最常被忽略的是：recover 后的代码，你以为它“恢复了”，其实变量状态可能已经错乱；还有就是以为 defer + recover 能管住所有 goroutine，结果线上崩溃查不出原因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
