panic 默认导致当前 goroutine 崩溃，未被 recover 捕获时程序退出；它触发栈展开、执行 defer（LIFO），不立即终止进程；recover 仅在 defer 中有效且仅捕获本 goroutine 最近一次 panic。
是的，panic 默认会导致当前 goroutine 崩溃，若发生在 main goroutine 且未被 recover 捕获，整个程序会退出。
panic 不等于立即 kill 进程，但会触发栈展开
当 panic 被调用或由运行时触发（如数组越界、nil 指针解引用），Go 不会立刻终止进程，而是启动「栈展开」过程：逐层返回调用栈，执行每个函数中已注册的 defer 函数（按 LIFO 顺序）。只有所有 defer 执行完、且未遇到 recover，程序才真正崩溃并打印堆栈。
- 即使 panic 发生，
defer fmt.Println("cleanup")依然会输出 - panic 后的代码（如
fmt.Println("never reached")）一定不会执行 - 多个嵌套
defer会全部执行，无论 panic 发生在哪个位置
recover 只在 defer 中有效，且仅捕获本 goroutine 的 panic
recover 不是全局异常处理器，它必须出现在 defer 函数体内才可能生效；而且只能捕获**当前 goroutine** 最近一次未被处理的 panic。跨 goroutine 的 panic 无法直接 recover —— 这是常见误判点。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 写成
if err := recover(); err != nil { ... }但没包在defer func() { ... }()里 → 永远返回nil - 在子 goroutine 中 panic，main 里 defer + recover → 完全无效
- recover 成功后，程序从 defer 函数返回后继续执行，不是“回到 panic 那行”
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("捕获到:", r) // 输出: 拦截成功
}
}()
panic("拦截成功")
fmt.Println("这行不会打印")
}panic vs os.Exit：退出方式和可观测性差异大
两者都让程序停止，但行为完全不同：os.Exit 是硬退出，不执行任何 defer，也不输出堆栈；而 panic 会完整走 defer 流程，并默认打印带文件行号的 panic 信息，对调试更友好。
- 用
os.Exit(1)退出服务？资源可能泄漏（文件未 close、连接未 shutdown） - 用
panic("config missing")初始化失败？合理，因为不可恢复且需快速暴露问题 - 高频业务逻辑里用 panic 处理参数校验？危险，性能差且掩盖真实错误类型
哪些场景该用 panic，哪些坚决不该
Go 社区共识很明确：panic 仅用于「绝不该发生」的编程错误，而非业务异常。比如配置加载失败、数据库连不上、HTTP 请求超时——这些都该返回 error，由上层决定重试、降级或告警。
- ✅ 适合 panic：初始化阶段致命错误（
flag.Parse()后发现必要 flag 缺失）、断言失败（v, ok := x.(string); if !ok { panic(...) }）、违反内部 invariant - ❌ 禁止 panic：用户输入校验、网络 IO 错误、第三方 API 返回非 200、可预期的空值处理
- ⚠️ 警惕伪“不可恢复”：日志写入失败？应 fallback 到 stderr 或内存缓冲，而不是 panic
最常被忽略的一点：recover 捕获后，你拿到的是 interface{} 类型的 panic 值，如果原 panic 是 panic(errors.New("xxx"))，recover 返回的就是那个 error 实例——别假设它一定是 string。
