Go中error和panic有什么区别_Go异常处理方式全面对比

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。