recover必须在同goroutine的defer匿名函数中调用才能捕获panic，跨goroutine无效；需类型断言安全使用返回值，不可滥用替代error处理。
panic 会直接终止当前 goroutine，不是全局中断
很多人误以为 panic 会像 Python 的 raise 那样“抛出后等待上层捕获”，其实它默认行为是终止当前 goroutine，并打印堆栈——除非你显式用 recover 拦截。这点特别关键：没 recover 的 panic 不会跨 goroutine 传播，也不会影响其他并发任务。
所以沙箱必须在同一个 goroutine 内完成 panic → recover 的闭环，常见错误是把待执行逻辑扔进新 goroutine 后再 defer recover，结果 recover 永远不生效。
- 正确做法：所有受控代码必须和
recover在同一函数作用域内，且recover()必须出现在defer中 - 典型错误写法：
go func() { ... panic(...) }()+ 外层defer recover()—— 这里 recover 拦不到子 goroutine 的 panic -
recover()只在 defer 函数中有效，且仅对当前 goroutine 最近一次 panic 生效；多次 panic 时，只有最后一次能被 recover 捕获
recover 必须紧跟 defer，且不能放在独立函数里
recover() 不是普通函数，它的行为依赖于 Go 运行时对当前 goroutine 的 panic 状态快照。一旦离开 defer 函数体，状态就清空了。这意味着你不能把 recover 提取成一个单独的工具函数调用。
比如下面这段看似整洁的代码是无效的：
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
func safeRun(f func()) {
defer func() {
if r := recover(); r != nil {
log.Printf("caught: %v", r)
}
}()
f()
}
这段本身没问题，但如果你写成：
func catchPanic() interface{} {
return recover() // ❌ 错误：recover 不在 defer 函数里，永远返回 nil
}
func safeRun(f func()) {
defer catchPanic() // 这里只是调用，不是 defer 执行 recover
f()
}
-
recover()必须直接写在defer关联的匿名函数或函数字面量内部 - 不能用变量保存
recover的返回值再判断，因为调用时机不对 - 如果需要复用 recover 逻辑，只能复用整个 defer 块，而不是 recover 调用本身
recover 捕获的是 interface{}，类型断言容易 panic
recover() 返回 interface{}，但实际值可能是 string、error，也可能是用户自定义类型（比如 panic(MyError{})）。直接用 fmt.Sprintf("%v", r) 虽安全，但丢失上下文；若想做精细处理，必须类型断言——而断言失败会再次 panic。
- 推荐先用
if r, ok := recover().(error); ok判断是否为 error 类型 - 若不确定 panic 类型，应优先用
fmt.Sprint(r)或fmt.Printf("%+v", r)输出原始值，避免二次崩溃 - Go 1.20+ 支持
panic(err)传入非 error 类型，所以不要假设 panic 值一定是 error - 沙箱中若需统一错误分类，建议在 panic 前主动包装成标准 error，例如
panic(fmt.Errorf("sandbox fail: %w", err))
沙箱无法拦截 runtime 异常（如 nil pointer dereference）
panic 和 recover 只对显式调用 panic() 或运行时检测到的严重错误（如数组越界、nil map 写入）生效，但对某些底层 crash 是无能为力的——比如真正的空指针解引用（(*T)(nil).Method()）、栈溢出、CGO 崩溃、或 syscall 失败导致的 SIGSEGV。
- 这类问题会直接终止进程，
recover完全无效 - 沙箱能兜住的只是“Go 层 panic”，不是“操作系统级信号”
- 若业务涉及 CGO 或 unsafe 操作，沙箱必须配合外部进程隔离（如 fork 子进程）才能真正容错
- 简单场景下，可通过
runtime/debug.SetPanicOnFault(true)将部分硬件异常转为 panic（仅限 Linux/AMD64，且有性能开销）
沙箱的边界很清晰：它只是一层控制流劫持机制，不是虚拟机。真正难缠的，永远是那些绕过 Go 运行时检查的底层操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
