go 的 panic 和 recover 是基于调用栈回溯与 defer 延迟执行的协作机制，非传统异常处理；panic 触发后立即终止当前函数，逐层执行已注册 defer（LIFO），若无 recover 则程序崩溃；recover 必须在 defer 函数内调用才有效，且仅能捕获同 goroutine 内 panic，成功后停止栈回溯、继续执行 defer 剩余代码并恢复程序运行。
Go 的 panic 和 recover 不是传统意义上的“异常捕获”，而是一套基于调用栈控制与延迟执行的协作机制。它不依赖 try-catch 结构，而是靠 defer 作为桥梁，在 panic 触发后、程序崩溃前插入恢复逻辑。
panic 触发后发生了什么
当调用 panic(v) 时：
- 当前函数立即停止执行，后续语句（包括 return）全部跳过
- 开始向上回溯调用栈，逐层退出函数，但每退出一个函数，都会先执行其已注册的
defer函数（按后进先出顺序） - 如果回溯到最外层仍没遇到
recover，程序打印 panic 信息并终止 - panic 是 goroutine 局部的，一个 goroutine 的 panic 不会影响其他 goroutine
recover 必须在 defer 中调用
recover() 只有在被 defer 包裹的函数内调用才有效：
- 若在普通函数或未 defer 的闭包中调用，返回
nil，起不到捕获作用 - defer 函数必须在 panic 发生前已注册（即 defer 语句要写在 panic 之前）
- 多个 defer 中，只有最靠近 panic 的那个含 recover 的 defer 能真正捕获（后注册、先执行）
recover 捕获后的执行流程
一旦 recover() 成功捕获 panic：
- 当前 goroutine 的栈回溯立刻停止，不再继续向上抛
- defer 函数继续执行完剩余代码（recover 后面的语句照常运行）
- 原 panic 的函数彻底退出，控制权回到 defer 所在函数的下一行（不是 panic 那行）
- 程序不会崩溃，可继续正常执行后续逻辑
goroutine 边界限制很关键
recover 无法跨 goroutine 生效：
- 主 goroutine 中的 defer + recover 不能捕获子 goroutine 的 panic
- 子 goroutine 内部必须自己设置 defer + recover，否则该 goroutine 会静默崩溃（仅打印 panic 日志）
- 常见错误：在 go func() { … panic(…) } 外层 defer recover，这完全无效
基本上就这些。机制不复杂，但容易忽略 defer 时机、goroutine 隔离和 recover 调用位置这三个关键点。