会执行，且仅执行panic前已注册的defer；go在栈展开前强制按lifo顺序执行所有已入栈defer，无论panic是否被recover捕获。
panic触发后defer还会执行吗
会，而且一定会执行——前提是defer语句在panic发生前已注册成功。Go 的运行时保证：只要defer语句已求值（即函数和参数已确定），即使后续调用panic，该defer仍会被执行，且按“后进先出”顺序（LIFO）倒序执行。
defer在panic前没执行完就panic了怎么办
常见于defer注册的是一个闭包或带参数的函数调用，而参数在注册时就被求值。如果参数求值过程本身 panic（比如索引越界、空指针解引用），那么defer根本不会被注册，自然也不会执行。
-
defer fmt.Println(arr[100])：若arr长度不足 101，这行语句执行时就 panic，defer未注册成功 -
defer func() { fmt.Println(arr[100]) }()：闭包体在真正执行时才求值，此时defer已注册，panic 发生在 defer 执行阶段，不影响其他已注册的 defer - 想安全延迟执行，优先用匿名函数包裹，避免参数提前求值引发注册失败
recover必须在defer里调用才有效
recover只有在defer函数中直接调用才起作用；如果 defer 调用的是另一个函数，而那个函数里写了recover，那就无效——因为recover只对当前 goroutine 中最近一次未被捕获的panic起作用，且必须在 panic 正在展开、尚未退出当前函数时调用。
- ✅ 正确：
defer func() { recover() }() - ❌ 无效：
defer helper(); func helper() { recover() } - ⚠️ 注意：
recover()返回nil表示没有 panic 正在发生，不能靠它判断“是否可能 panic”，只能用于捕获
主函数里panic后程序就退出，defer还来得及打印日志吗
来得及，但有前提：log 输出必须是同步的，且不能依赖被 panic 中断的资源（比如已关闭的文件、失效的网络连接）。标准log.Println默认是同步写os.Stderr，所以通常能输出；但如果你用了异步 logger（如 zap 的 logger.Sync() 没显式调），那日志可能丢失。
- 推荐在关键 defer 中加
log.Printf("cleanup: %v", err)这类明确副作用的操作 - 避免在 defer 中做耗时操作（如 HTTP 请求、数据库 commit），panic 后程序很快退出，超时或中断风险高
- 多个 defer 嵌套时，外层 defer 的 recover 只能捕获内层 panic，无法跨函数边界“穿透”
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
