17370845950

Go 没有 try/catch 是因设计上坚持错误必须显式处理，error 作为接口类型通过多返回值传递，panic 仅用于不可恢复崩溃，recover 仅为同 goroutine 兜底而非错误处理机制。

Go 为什么没有 try/catch

Go 明确拒绝在语言层面引入异常（exception）机制，不是遗漏，而是设计选择。核心原因是：错误必须显式处理，不能被意外忽略。这直接反映在 error 是一个接口类型、函数返回值中常带 error、且编译器不强制检查但社区约定必须检查——而像 panic 则专用于真正不可恢复的程序崩溃场景，比如空指针解引用、切片越界、栈溢出。

error 接口和多返回值是 Go 错误处理的基础设施

Go 把错误当作普通值来传递和判断，依赖函数签名约定和开发者自律。典型模式是：func DoSomething() (result, error)。这种设计让错误路径和正常路径在代码中并列可见，避免了 try/catch 块造成的控制流“断裂”和嵌套加深。

• error 接口仅含一个 Error() string 方法，轻量、可自定义实现（比如带堆栈、带 HTTP 状态码的错误）
• 标准库大量使用 errors.New 和 fmt.Errorf，后者支持格式化与嵌套（Go 1.13+ 的 %w 动词）
• 不要用 panic 替代 error：HTTP handler 中调用 json.Unmarshal 失败应返回 400 Bad Request + error，而不是 panic —— 后者会终止 goroutine，还可能让整个服务不可用

recover 不是 catch，它只用于兜底，不能替代错误处理

recover 只能在 defer 函数中生效，且仅对同 goroutine 中由 panic 触发的崩溃有效。它不是错误处理机制，而是程序韧性手段。

func safeCall(f func()) {
	defer func() {
		if r := recover(); r != nil {
			log.Printf("recovered from panic: %v", r)
		}
	}()
	f()
}

• recover 无法捕获其他 goroutine 的 panic
• 无法捕获系统级错误（如 OOM、SIGKILL）
• 不应在业务逻辑中用 recover 来“吞掉”本该返回 error 的失败，比如文件打开失败、数据库连接超时

常见误用：把 error 当成 panic，或把 panic 当成 error

这两类混淆会导致程序行为难以预测。例如：

• 在 http.HandlerFunc 中对 req.Body 调用 io.ReadAll 后忽略返回的 error，导致后续解析 JSON 时 nil 数据触发 panic —— 这本该在第一层就返回 400
• 用 log.Fatal 终止主 goroutine，却忘了它底层调用 os.Exit(1)，不会执行任何 defer，也不会关闭监听端口或释放资源
• 在 defer 中调用 recover() 后不 re-panic 或不记录，等于静默丢弃崩溃信号，调试时完全看不到线索

真正难的不是语法，而是判断：这个失败是“预期中的可恢复事件”，还是“程序已处于非法状态”。前者走 error 返回，后者才考虑 panic。多数业务错误都属于前者。