error用于可预期、可恢复的业务失败，如文件打开失败；panic仅用于程序无法继续的致命错误，如初始化崩溃。二者目的不同，不可混用。
error 是你该检查的错误，panic 是你该修复的崩溃。 它们不是两种“错误处理方式”的并列选项，而是服务于完全不同的目的：一个属于业务流程，一个属于程序存亡。
什么时候该用 error？——所有可预期、可恢复的失败
比如打开文件失败、HTTP 请求超时、JSON 解析出错、数据库查不到记录……这些不是 bug，是常态。Go 要求你显式面对它们，而不是藏在 try-catch 里。
- 必须作为返回值暴露：
func ReadConfig() (Config, error)，调用方不检查err != nil就继续往下走，就是逻辑漏洞 -
标准库几乎全走这条路：
os.Open、json.Unmarshal、http.Get都返回error - 自定义错误推荐用
errors.New或fmt.Errorf，严重时加错误码和上下文（如时间、请求 ID） - 别把
error当日志用——它要被处理，不是被打印完就丢掉
什么时候该用 panic？——只在程序根本没法继续时
比如启动时连不上数据库、配置文件语法错到无法解析、全局单例被重复初始化、或者你写了 arr[100] 却忘了切片长度是 5。这些不是“用户输错了”，是代码写错了，或者环境彻底崩了。
- 仅限初始化阶段或不可恢复的内部故障；业务逻辑中手动
panic("user not found")是反模式 - 标准库只在真正“不可能发生”时 panic：
sync.(*Mutex).Lock对已锁定的 mutex 再锁，reflect非法操作类型 - 不要指望靠
recover把 panic “转成 error” 来兜底——那只是防止服务整体挂掉，不是让业务逻辑恢复正常 - 如果你发现自己在多个地方写
defer func() { if r := recover(); r != nil { ... } }()，说明 panic 用滥了
recover 不是异常捕获，是崩溃前的最后清理
它只在 defer 函数里有效，且只能捕获当前 goroutine 的 panic。它不能让你“继续执行原逻辑”，只能做三件事：记日志、关资源、优雅退出。
func serveRequest() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
// 注意：这里不能 return 正常响应，也不能重试原请求
// 只能清理，比如 close(conn), rollback(tx)
}
}()
handle(req) // 可能 panic
}
-
recover不是 Go 的 try-catch，它不提供“异常类型匹配”或“多级 catch” - 在 HTTP handler 顶层加 recover 是常见做法，但目的是保进程不死，不是保这次请求成功
- 滥用 recover 会让 panic 隐藏在深层调用中，导致问题更难定位
最容易混淆的坑：把业务错误升级成 panic
比如“用户未登录”返回 401 是 error；但你在中间件里写了 if user == nil { panic("no user") }，就等于把一个 HTTP 层面的常规状态，变成了整个 goroutine 的崩溃信号。
- 判断依据很简单：这个错误发生后，其他请求还能不能处理？如果能，就是
error - 数据库连接失败，在
main()初始化时 panic 合理；但在某个 API 里查一条数据失败，应该返回error并返回500或重试 - panic 的堆栈里如果频繁出现你的业务函数名（而非 runtime 或 sync 包），基本可以断定用错了
真正难的不是语法，是判断“这算不算程序还能活”。很多团队踩坑，是因为把 panic 当成了“带堆栈的日志”，或者把 error 当成了“不够严重的警告”。区分清楚，代码才不会在半夜因为一个 404 而整个服务 restart。
