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
这两类混淆会导致程序行为难以预测。例如：
立即学习“go语言免费学习笔记（深入）”；
- 在
http.HandlerFunc中对req.Body调用io.ReadAll后忽略返回的error，导致后续解析 JSON 时nil数据触发 panic —— 这本该在第一层就返回400 - 用
log.Fatal终止主 goroutine，却忘了它底层调用os.Exit(1)，不会执行任何defer，也不会关闭监听端口或释放资源 - 在 defer 中调用
recover()后不 re-panic 或不记录，等于静默丢弃崩溃信号，调试时完全看不到线索
真正难的不是语法，而是判断：这个失败是“预期中的可恢复事件”，还是“程序已处于非法状态”。前者走 error 返回，后者才考虑 panic。多数业务错误都属于前者。
