recover不是catch，它不恢复执行流而仅阻止崩溃；必须在panic前的defer匿名函数中调用，否则返回nil；每个goroutine需独立处理panic，recover后函数立即终止，不可继续执行后续代码。
Go 里 recover 不是“catch”——它不恢复执行流，只阻止崩溃；想让它生效，必须在 defer 匿名函数里调用，且 defer 必须写在 panic 之前。
recover 必须在 defer 匿名函数中调用
直接写 recover() 永远返回 nil，哪怕它离 panic 只有一行。Go 的运行时只在栈展开过程中、且当前 goroutine 尚未退出时才允许 recover 拿到 panic 值。
-
defer是唯一能“卡住”栈展开、让recover有机会介入的机制 - 必须用匿名函数包裹：
defer func() { r := recover(); ... }()，不能写成defer recover()（那是立即执行） - 常见翻车：把
recover()放在 if 分支、普通语句块或非 defer 函数里，结果什么也捕不到
每个 goroutine 都得自己加 recover
panic 不跨 goroutine 传播，主 goroutine 的 defer+recover 对子协程完全无效。一个没包 recover 的 go func() 崩了，只会静默退出，可能卡住 channel、漏跑定时任务、甚至让数据库连接泄漏。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- HTTP handler 中的中间件 recover 只管当前请求协程，不管后台 worker
- 推荐封装
goSafe工具函数，在启动 goroutine 时自动注入defer func() { recover(); debug.Stack() }() - 别依赖“全局兜底”——Go 没有全局异常处理器，只有每个 goroutine 自己的局部防御
recover 后函数立即 return，不会继续执行 panic 后代码
很多人误以为 recover 后能“接着跑”，比如期望 panic 后面的 fmt.Println("done") 还能执行。实际是：recover 捕获后，当前函数立刻终止，后续语句全部跳过。
- 想实现“失败后重试”或“降级逻辑”，得靠业务层主动判断，不是 recover 自带能力
- 如果需要清理资源（如关闭文件、释放锁），必须把清理逻辑写在 defer 里，而不是 panic 后的普通语句中
- recover 返回的是
interface{}，建议做类型断言：if err, ok := r.(error); ok，避免对字符串 panic 做错误处理
panic 只该用于不可恢复的编程错误
用 panic("user not found") 或 panic(fmt.Errorf("timeout")) 是反模式。Go 的设计哲学是显式错误处理，error 返回值才是业务错误的正道。
- panic 应仅限于：空指针解引用、数组越界、类型断言失败、违反不变量等真正无法继续执行的场景
- 滥用 panic 会让调用方无法静态检查错误路径，破坏接口契约，也容易导致 goroutine 泄漏
- 线上服务中，panic 要搭配结构化日志和 traceID，否则光看
"interface {}" is nil根本没法定位问题源头
最常被忽略的一点：recover 不是安全网，而是最后一道手动闸门。它不改变 panic 的语义，也不修复状态——你得自己确保 defer 里的清理逻辑正确，且每个并发入口都独立覆盖。写错一行 defer 位置，整个恢复逻辑就失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
