panic 是 Go 中用于处理严重错误的机制，触发后中断 goroutine 并向上传播直至被 recover 捕获或程序终止；常见自动触发场景包括空指针解引用、越界访问、关闭已关闭的 channel、类型断言失败等；recover 仅在 defer 中对当前 goroutine 的 panic 有效，可停止传播并获取 panic 值，但不能跨 goroutine 恢复；典型用法是在 defer 中调用 recover 进行日志记录或资源清理，避免掩盖逻辑错误；与 os.Exit 和 log.Fatal 不同，panic 会执行 defer 且可恢复，而后者直接退出不执行 defer；适合在 HTTP handler 等场景使用 recover 防止服务整体崩溃。
panic 在 Go 中不是异常，而是程序遇到无法继续执行的严重错误时主动崩溃的机制。 它会立即中断当前 goroutine 的正常流程，开始向上逐层调用 栈 panic，直到被 recover 捕获，或最终导致整个程序终止。
哪些情况会自动触发 panic
Go 运行时会在以下常见场景自动抛出 panic（无需手动调用）：
- 空指针解引用（如对 nil *T 进行取值操作）
- 切片或数组越界访问（
s[10]超出长度） - 向已关闭的 channel 发送数据
- 关闭一个 nil 或已关闭的 channel
- 类型断言失败且未使用“逗号 ok”语法（如
x.(T)失败） - 调用 panic 函数（显式触发）
panic 的传播与 recover 的生效条件
recover 只能在 defer 函数中调用才有效，且仅对 ** 当前 goroutine** 中正在发生的 panic 生效。
- 必须在 defer 中调用，且该 defer 必须在 panic 发生前已注册
- recover 一旦成功捕获 panic，就会停止 panic 传播，并返回 panic 参数（通常是 error 或 string）
- recover 在非 panic 状态下调用会返回 nil，不报错也不起作用
- 不能跨 goroutine 恢复：goroutine A panic，goroutine B 的 recover 无效
典型恢复写法与注意事项
标准 recover 模式如下：
立即学习“go 语言免费学习笔记（深入）”；
func safeCall() { defer func() {if r := recover(); r != nil {log.Printf("panic recovered: %v", r) } }() // 可能 panic 的代码 panic("something went wrong") }- recover 返回值是 interface{}，常需类型断言判断具体类型（如
r.(error)） - 不要滥用 recover 隐藏真正错误；它适合做清理、日志、优雅降级，而非掩盖逻辑缺陷
- 避免在顶层函数（如 main）里无条件 recover —— 这会让问题难以调试
- HTTP handler 中常用 recover 防止一个请求 panic 导致整个服务挂掉
panic vs os.Exit vs log.Fatal
三者都会终止程序，但行为不同：
-
panic：触发 defer、可被 recover、只影响当前 goroutine（若未 recover 则退出进程） -
os.Exit(code)：立即退出进程，** 忽略所有 defer**，不运行任何清理逻辑 -
log.Fatal：等价于log.Print + os.Exit(1)，同样跳过 defer
需要资源清理或中间件拦截时，优先选 panic + recover；确定要立刻退出且无需清理时，用 os.Exit。
基本上就这些。panic 不是 bug，而是 Go 明确表达“这里不能继续”的方式 —— 关键是理解它何时来、怎么停、以及什么时候不该拦。
