必须用 panic 的场景包括：程序启动时关键依赖缺失、函数调用方明显违反前置条件、类型断言本应 100% 成功却失败、手动检查到绝不能发生的 bug（如除零）。

只在程序根本无法继续运行时才用 panic，比如初始化失败、逻辑断言被破坏、或遇到本不该发生的运行时错误。

哪些场景下必须用 panic？

不是所有“出错了”都要 panic —— Go 的设计哲学是：可预期的错误（如文件不存在、网络超时）必须返回 error；只有那些“程序已经失去意义”或“代码存在 bug”的情况，才该触发 panic。

• 程序启动时关键依赖缺失：init() 中读取配置失败、连接数据库失败且无 fallback 方案
• 函数调用方明显违反前置条件：传入 nil 指针到明确要求非空的内部函数中
• 类型断言失败且本应 100% 成功：v, ok := data.(*User); if !ok { panic(...) }，说明调用链有逻辑错误
• 运行时自动 panic 的等价主动行为：如手动检查除零并 panic("divide: b is zero")，用于标记“这里绝不能发生”的 bug

为什么不能用 panic 处理业务错误？

因为 panic 会中断调用栈，绕过正常错误传播路径，调用方无法选择重试、降级或记录上下文。它剥夺了错误处理的控制权，也违背 Go 的显式错误哲学。

• 例如：os.ReadFile("config.yaml") 返回 error 是标准流程；若改成 panic，上层就无法区分“配置文件临时不可读”和“配置结构彻底损坏”
• HTTP handler 中对请求参数校验失败，应返回 400 Bad Request + 错误信息，而不是 panic 导致整个 goroutine 崩溃
• 库作者尤其要避免对外暴露 panic —— 用户无法 recover 你没文档化的 panic，容易引发线上雪崩

recover 不是 try-catch，别滥用兜底

recover 只能在 defer 函数中生效，且只能捕获当前 goroutine 的 panic。它不是用来“吞掉错误继续跑”，而是做最后的资源清理、日志记录或服务级防护。

• 正确位置：HTTP 中间件、main() 入口、长期运行的 goroutine 最外层
• 错误做法：在每个工具函数里都加 defer recover()，这会让错误静默、掩盖真正问题
• 注意：recover() 捕获后，函数不会回到 panic 发生点继续执行，而是直接退出 —— 它只防止崩溃，不恢复业务状态
• 性能影响：频繁 panic/recover 会显著拖慢程序，因为涉及栈展开和调度器介入，不应作为控制流手段

怎么判断该不该 panic？一个快速自查清单

写完一行 panic(...) 前，问自己三个问题：

• 这个错误是否意味着程序已处于“不可修复的非法状态”？（比如全局配置未加载，后续所有 handler 都会错）
• 这个错误是否暴露了开发阶段就该发现的 bug？（比如某个接口契约被调用方持续违反）
• 有没有可能让调用方安全地处理它？如果答案是“有”，那就该返回 error，而不是 panic

最容易被忽略的一点是：panic 的参数类型建议统一用 error 或带堆栈信息的字符串，避免裸字符串导致日志难以归因 —— 尤其在微服务链路中，缺少上下文的 "config load failed" 几乎无法定位根因。