panic 不传递结构体数据，仅接收 interface{}；可传结构体或其指针用于调试定位或异常上下文标记，但绝不可用于控制流或错误处理。
Go 的 panic 函数本身不“传递结构体数据”，它只接收任意类型值（interface{}），但你可以安全、可控地把结构体（或其指针）作为 panic 参数传入——前提是明确目的：仅用于调试定位或异常上下文标记，**绝不可用于控制流或错误处理**。
panic 里传结构体常见错误现象
直接传结构体值或指针看似可行，但容易引发两类问题：
- panic 输出不可读：如果结构体字段多、嵌套深，
panic(&MyStruct{...})打印出的堆栈末尾是一长串未格式化的内存地址或空结构体表示，无法快速识别关键字段 - 掩盖真正错误：用
panic包裹本该用error返回的业务错误（比如参数校验失败），导致调用方无法if err != nil处理，反而必须靠recover拦截——这违反 Go 错误处理约定，且 recover 难以精准匹配 panic 类型 - 结构体含未导出字段或非可打印类型（如
sync.Mutex）时，panic可能触发额外 panic 或输出<nil></nil>
什么时候可以传结构体到 panic
仅限以下真实场景，且结构体应轻量、字段全部导出、语义清晰：
- 内部断言失败时携带上下文：比如在测试工具或 debug 模式下，断言某个结构体字段必须为非零值，失败时附带该结构体便于排查
- 运行时 invariant 被破坏：例如一个全局状态机结构体
State的Phase字段被非法修改为无效值，此时panic(&State{...})是合理兜底 - 自定义 panic 类型封装：定义一个带结构体字段的 error-like 类型（如
type PanicInfo struct { Code int; Msg string; Data map[string]interface{} }），再panic(PanicInfo{...})
示例：
立即学习“go语言免费学习笔记（深入）”；
type ValidationError struct {
Field string
Value interface{}
Rule string
}
func validateUser(u *User) {
if u.Age < 0 {
panic(ValidationError{
Field: "Age",
Value: u.Age,
Rule: "must be non-negative",
})
}
}
为什么不要传大结构体或含指针的结构体
结构体大小和内容直接影响 panic 的可观测性与安全性：
- 值传递大结构体会拷贝全部字段，增加 panic 开销；指针传递虽省空间，但若结构体后续被修改，panic 打印时看到的可能是脏数据
- 结构体中含
http.Request、*sql.DB等资源句柄时，panic 后这些对象不会自动释放，可能引发泄漏（虽然 goroutine 会终止，但资源清理非 panic 职责） - JSON 序列化字段（如
json:"id"）在 panic 输出中不可见，除非结构体实现了String()方法
更稳妥的做法是提取关键字段构造简洁消息：
// ❌ 不推荐：传整个结构体
panic(user)
// ✅ 推荐：只传必要标识
panic(fmt.Sprintf("invalid user age=%d, id=%s", user.Age, user.ID))
recover 怎么安全取回 panic 的结构体
recover() 返回的是 interface{}，需显式类型断言才能访问字段。必须检查断言是否成功，否则会 panic：
defer func() {
if r := recover(); r != nil {
if info, ok := r.(ValidationError); ok {
log.Printf("Validation failed: %s = %v (%s)", info.Field, info.Value, info.Rule)
} else {
log.Printf("Unknown panic: %v", r)
}
}
}()
注意：recover 只在 defer 函数中有效，且只能捕获当前 goroutine 的 panic；跨 goroutine panic 无法被 recover。
真正难的不是怎么传结构体，而是判断该不该用 panic——绝大多数业务逻辑错误都应该走 error 返回路径。结构体进 panic，只应是最后一道防线，且必须确保它能被日志系统捕获、解析、告警，而不是藏在堆栈里无人问津。
