Go 语言中 panic 表示不可恢复的严重错误，recover 仅能在 defer 中且仅对同 goroutine 的 panic 有效，不能拦截 error；正确用法是在 HTTP handler 等外层加 defer+recover 防止服务崩溃。
Go 语言没有传统意义上的“异常捕获”机制（比如 Java 的 try/catch 或 Python 的 try/except），panic 不是用于常规错误处理的工具，而是表示**不可恢复的严重错误**，比如空指针解引用、切片越界、调用 panic() 显式中断等。你无法用 panic “捕获异常”来继续执行逻辑——它默认会终止当前 goroutine，并向上冒泡直至程序崩溃。
为什么不能用 recover 拦截任意错误
recover 只能在 defer 函数中、且仅在当前 goroutine 发生 panic 时才有效。它不是全局异常处理器，也不能拦截 error 值（比如 os.Open 返回的 error）。
-
recover()必须紧贴在defer调用内，且该defer必须在panic触发前已注册 - 一旦
panic发生，当前函数立即停止执行，后续语句（包括其他defer）按栈逆序执行 -
recover()只对本 goroutine 有效；主 goroutine 中 panic 未被 recover，整个程序退出
正确使用 recover 阻止 panic 波及主流程
典型场景：在 HTTP handler 或长期运行的 goroutine 中防止一个 panic 导致整个服务宕机。关键在于把 recover 放进最外层 defer，并确保它在 panic 后能拿到 panic 值。
func safeHandler() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
// 这里可记录日志、上报指标、返回 fallback 响应等
}
}()
// 可能 panic 的代码，例如：
_ = []int{1, 2}[5] // slice bounds out of range
}- 必须用
func() { ... }()立即执行匿名函数，否则defer注册的是函数字面量而非调用结果 -
recover()返回interface{}，需类型断言才能获取原始 panic 值（如r.(string)或fmt.Sprintf("%v", r)） - 不要在 defer 里直接写
recover()（如defer recover()），它不会生效
panic 和 error 的分工必须清晰
绝大多数业务错误（文件不存在、网络超时、参数校验失败）应该返回 error，而不是触发 panic。滥用 panic 会让调用方失去控制权，也违背 Go 的显式错误处理哲学。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“go语言免费学习笔记（深入）”；
-
panic适合：程序启动失败（配置加载异常）、不可恢复的内部状态（如 mutex 已解锁却再次 unlock）、断言失败（assert类逻辑） -
error适合：所有可预期、可重试、可降级的失败场景 - 第三方库若内部用了
panic（如某些正则匹配库对非法 pattern 的处理），你只能靠外层recover拦截，但这是防御性措施，不是设计常态
goroutine 中 panic 的 recover 容易漏掉
新起的 goroutine 是独立的执行单元，主 goroutine 的 defer/recover 对它完全无效。每个可能 panic 的 goroutine 都要自己加保护。
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("worker goroutine panicked: %v", r)
}
}()
doSomethingRisky()
}()漏掉这个，就是典型的“后台任务 panic 导致进程静默退出”，日志里只有一行 fatal error: all goroutines are asleep - deadlock? 或直接消失——因为 panic 后 goroutine 终止，又没其他 goroutine 推进，主函数提前退出。
