必须用 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。它不是用来“吞掉错误继续跑”，而是做最后的资源清理、日志记录或服务级防护。
立即学习“go语言免费学习笔记（深入）”；
- 正确位置：HTTP 中间件、
main()入口、长期运行的 goroutine 最外层 - 错误做法：在每个工具函数里都加
defer recover()，这会让错误静默、掩盖真正问题 - 注意：
recover()捕获后，函数不会回到 panic 发生点继续执行，而是直接退出 —— 它只防止崩溃，不恢复业务状态 - 性能影响：频繁 panic/recover 会显著拖慢程序，因为涉及栈展开和调度器介入，不应作为控制流手段
怎么判断该不该 panic？一个快速自查清单
写完一行 panic(...) 前，问自己三个问题：
- 这个错误是否意味着程序已处于“不可修复的非法状态”？（比如全局配置未加载，后续所有 handler 都会错）
- 这个错误是否暴露了开发阶段就该发现的 bug？（比如某个接口契约被调用方持续违反）
- 有没有可能让调用方安全地处理它？如果答案是“有”，那就该返回
error，而不是 panic
最容易被忽略的一点是：panic 的参数类型建议统一用 error 或带堆栈信息的字符串，避免裸字符串导致日志难以归因 —— 尤其在微服务链路中，缺少上下文的 "config load failed" 几乎无法定位根因。
