panic仅用于程序无法继续运行的致命错误，如初始化失败、逻辑错误或运行时越界；可预期的业务错误必须返回error，不可滥用panic或recover。
panic 只该用在程序根本没法活下去的时候，其他情况一律用 error。
哪些错误必须 panic？——初始化失败、逻辑崩坏、运行时越界
不是所有“出错了”都要 panic。Go 的设计哲学是：可预期的失败（比如文件不存在、HTTP 超时）必须返回 error；只有那些说明代码写错了、配置丢了、或系统状态彻底乱套的情况，才值得 panic。
- 启动时关键依赖缺失：比如
init()里loadConfig("config.yaml")失败，后续所有逻辑都无意义，直接panic - 函数调用明显违反前提条件：比如一个明确要求非 nil 的
*User参数被传了nil，这不是业务异常，是调用方 bug - 运行时自动触发的崩溃点：如
arr[100]（切片越界）、*nilPtr（空指针解引用）、i.(int)（类型断言失败且不加, ok判断）——这些 Go 自己就会 panic，你不用手写，但得知道它们为什么发生
哪些错误绝对不能 panic？——HTTP 错误、校验失败、资源未找到
把业务层面的失败当成 panic，等于把方向盘交给 runtime，调用方完全失去控制权。一旦 panic 没被 recover，整个 goroutine 就凉，还可能连带拖垮 HTTP handler。
-
http.Get返回err != nil？→ 返回error，让上层决定重试、降级或返回 502 -
json.Unmarshal解析失败？→ 返回error，而不是在库函数里panic("invalid JSON") -
FindUser(id)没查到？→ 返回(nil, fmt.Errorf("user %d not found", id))，不是panic
常见坑：if err != nil { panic(err) } 出现在业务函数里，尤其在 handler 或 service 层——这会让错误无法被分类、记录、重试，测试时还得硬套 recover，徒增复杂度。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
recover 怎么用才不算滥用？——仅限边界拦截，绝不用于流程控制
recover 不是 try-catch，它只在 defer 函数中直接调用才有效，且只能捕获当前 goroutine 的 panic。它存在的唯一合理理由，是防止一个 goroutine 的 panic 波及整个服务。
- HTTP handler 最外层加
defer + recover是常见做法，但目的只是兜底：记录日志 + 返回 500，不能 把 error 转成 success 响应 - 不要在普通业务函数里写
recover来“处理”自己panic的错误——那说明你本就不该 panic -
recover后程序不会回到 panic 那行继续执行，而是从 defer 函数返回后，执行 panic 所在函数的 下一行之后的外层逻辑（这点极易误解）
示例：defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }() —— 这行必须出现在 handler 入口，且仅此一处。
库作者怎么用 panic？——防御性检查可以，暴露 API 误用要果断
作为库作者，你要对使用者负责。对明显违背接口契约的调用，panic 是一种清晰、强硬的反馈方式，比静默失败或返回模糊 error 更利于快速定位问题。
-
if req == nil { panic("http: nil Request") }—— 标准库net/http就这么干，因为nil *Request没有任何合法语义 -
sync.Pool.Get()在 Pool 已关闭后被调用，会 panic —— 因为这是严重使用错误，不该被容忍 - 但不要对参数做业务校验就 panic：比如
SendEmail(to string)里检查to == ""就 panic？错，应该返回error
真正难的是分寸：什么算“契约破坏”，什么算“输入不合理”。经验法则是——如果这个错误在单元测试里能稳定复现，且修复后永远不该再出现，那它适合 panic。
最容易被忽略的一点：panic 的成本不只是崩溃，而是它绕过了所有正常的错误传播路径。一旦你开始依赖 recover 拦截 panic，就等于在代码里埋了隐式控制流分支，而 Go 的显式 error 返回值，本就是为了让你看得见、管得住每一次失败。
