Go的错误处理机制与Java截然不同：error用于可恢复的业务错误，通过if err != nil显式处理；panic/recover仅用于不可恢复的致命错误兜底，defer则负责函数级资源清理，非等价于finally。
Java 的 try-catch 是面向“可恢复异常”的结构化捕获机制，而 Go 的 defer + panic + recover 并不是等价替代，它本质是为**不可恢复的致命错误**设计的兜底手段，日常错误处理靠的是显式的 if err != nil。混淆这两套逻辑，是 Java 程序员转 Go 时最常踩的坑。
错误类型定位不同：error 不是 exception
Go 把“出错”明确分为两类：
-
error：比如文件打开失败、HTTP 请求超时、JSON 解析错误——这些是业务中可预期、应主动检查并处理的问题，通过返回值传递，用
if err != nil判断，不中断执行流； - panic：比如 nil 指针解引用、切片越界、并发写 map——这些是程序逻辑缺陷或灾难性故障，本不该发生，一旦触发，默认终止当前 goroutine。
Java 中所有异常（checked/unchecked）都走 try-catch 路线；Go 中绝大多数问题属于 error 范畴，panic 应该极少手动调用，更不该用来处理业务校验失败这类场景。
资源清理方式根本不同：defer 不是 finally
Java 的 finally 块在 try/catch 执行完毕后无条件运行，用于释放资源；Go 的 defer 是函数退出时（无论是否 panic）执行的延迟语句，但它不绑定在某段代码块上，而是作用于整个函数生命周期。
立即学习“Java免费学习笔记（深入）”；
- Java：
try { open(); work(); } finally { close(); }—— close 只在这一段逻辑结束时执行； - Go：
f := open(); defer f.Close(); work()—— close 在work()结束（或 panic 后 defer 链执行）时触发，语义更清晰、无嵌套、不易遗漏； - 注意：多个 defer 按后进先出（LIFO）顺序执行，类似栈；而 finally 总是按书写顺序执行。
异常捕获能力与范围受限：recover ≠ catch
recover 只能在 defer 函数中调用才有效，且只能捕获**当前 goroutine 中发生的 panic**，不能跨 goroutine 传播捕获。
- Java 的 catch 可捕获 try 块内任意位置抛出的异常，包括子方法、回调、第三方库；
- Go 的 recover 无法捕获 runtime 强制 panic（如“concurrent map writes”），也无法捕获其他 goroutine 的 panic；
- recover 返回的是 panic 传入的值（推荐用
error类型），但不会自动“吞掉”错误——你仍需记录日志、返回合理响应，否则只是掩盖了问题。
典型误用与正向实践
避免把 Go 当成“带 defer 的 Java”来写：
- ❌ 不要用 panic 处理参数校验失败：
if name == "" { panic("name required") }—— 应返回errors.New("name required")； - ✅ 只在真正无法继续时 panic：比如配置加载失败且无默认值、初始化关键组件失败；
- ❌ 不要在顶层 HTTP handler 里裸写 recover —— 容易掩盖 panic 根因；
- ✅ 在中间件中统一 recover + 日志 + 返回 500，并确保 defer 清理已分配资源（如关闭 response body）；
- ✅ defer 优先用于资源管理（file.Close()、rows.Close()、mutex.Unlock()），而非错误处理逻辑。
