应仅在程序无法继续执行的致命状态时用panic，如init中配置失败、空指针主动拦截；其他情况优先返回error。
什么时候该用 panic 而不是错误返回
Go 的设计哲学是优先用 error 处理可预期的失败，比如文件不存在、网络超时。只有当程序处于**无法继续执行的致命状态**时，才考虑 panic——例如初始化阶段配置严重错误、空指针解引用前主动拦截、或调用不安全的 C 代码前校验失败。
常见误用：在 HTTP handler 里对用户传参错误直接 panic，这会导致整个服务崩溃。正确做法是返回 http.Error 或结构化错误响应。
- 适合
panic的场景：init()中加载关键配置失败、全局单例未初始化就调用、断言失败且本不该发生（如类型断言后立即使用却没检查） - 不适合的场景：I/O 错误、用户输入校验失败、数据库查询无结果
-
panic不会自动记录堆栈到日志，需配合recover和日志库手动捕获
用 panic 模拟异常并用 recover 捕获
Go 中没有“抛出异常”和“捕获异常”的语法糖，panic 是运行时中断，必须在 defer 函数中用 recover 拦截，且仅对当前 goroutine 有效。
下面是一个典型模拟+捕获模式：
func riskyOperation() {
defer func() {
if r := recover(); r != nil {
fmt.Printf("panic captured: %v\n", r)
// 这里可记录日志、清理资源、或转换为 error 返回
}
}()
panic("something went very wrong")
}
-
recover()只在defer函数中调用才有效；放在普通函数里始终返回nil -
recover()只能捕获当前 goroutine 的panic，跨 goroutine 不生效 - 如果想把 panic 转为 error 向上返回，需在
recover后显式构造fmt.Errorf("wrapped: %w", r)类型值
测试中故意触发 panic 并验证行为
单元测试需要覆盖 panic 场景，但不能让测试进程崩溃。标准做法是用 recover 包裹被测函数调用，并检查是否如期 panic 及 panic 值是否匹配。
示例测试片段：
func TestDivideByZeroPanic(t *testing.T) {
defer func() {
r := recover()
if r == nil {
t.Fatal("expected panic, but none occurred")
}
if r != "division by zero" {
t.Fatalf("expected 'division by zero', got %v", r)
}
}()
divide(10, 0) // 假设这个函数内部调用 panic("division by zero")
}
- 测试函数本身不能 defer 到外部作用域，必须在测试函数体内写
defer func() { ... }() - 别用
os.Exit(1)替代panic来模拟——它会终止整个进程，测试框架无法继续运行后续用例 - 若被测函数已含
recover，测试时需先临时移除或通过构建标签禁用，否则 panic 会被静默吞掉
调试时快速定位 panic 起源的技巧
默认 panic 输出只包含最后一层调用栈，容易漏掉真正触发点。开启完整堆栈需设置环境变量或改用 runtime/debug.PrintStack()。
- 启动程序时加
GOTRACEBACK=crash，panic 时会打印完整 goroutine 栈（含其他 goroutine 状态） - 在
recover后手动调用debug.PrintStack()，可输出当前 goroutine 完整调用链 - 用
runtime.Caller(n)获取第 n 层调用的文件/行号，适合在自定义 panic 包装器中注入上下文 - 注意：生产环境慎用
GOTRACEBACK=all，可能泄露敏感路径或导致日志爆炸
最常被忽略的一点：panic 的参数类型可以是任意接口{}，但如果你传了指针或结构体，recover 拿到的是原始值还是副本，取决于你如何构造它——这会影响日志中看到的字段是否最新。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
