Go 不用 try/catch 是因设计上将错误视为普通值而非控制流；error 是接口，需显式声明、接收、检查，强制 if err != nil 习惯，确保错误路径可见、可追踪、无隐藏分支。
Go 不用 try/catch，是因为它从设计之初就拒绝把错误当作控制流——错误是值，不是跳转指令；处理错误是调用者的责任，不是运行时的自动兜底。
这背后不是技术做不到，而是 Go 团队反复权衡后主动选择的克制：显式、可追踪、无隐藏分支、不鼓励“吞掉错误”或“甩锅给上层”。
error 是接口，不是异常：为什么 if err != nil 是强制习惯
Go 把错误降级为普通返回值，意味着：
- 错误必须被声明、被接收、被检查（或明确忽略）
- 编译器不会帮你插
catch块，也不会因未处理而报错（但 linter 会警告） - 所有错误路径都出现在函数签名里，一眼可见
func fetchUser(id int) (*User, error) {
if id <= 0 {
return nil, errors.New("invalid user ID")
}
// ...
}常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 忘记检查
err，直接用返回值，导致 panic 或逻辑错乱 - 用
忽略 error（如, _ = doSomething()），掩盖真实失败 - 在 defer 中调用可能出错的函数（如
file.Close()）却不检查其error，丢失关闭失败信息
正确做法：
- 每次调用返回
error的函数，都写if err != nil分支（哪怕只是return err） - 用
errors.Is()或errors.As()判断错误类型，而不是字符串匹配 - 对关键资源（如 DB 连接、文件句柄）的
Close()，建议单独检查其 error 并记录（即使 defer 了）
panic/recover 不是 try/catch 替代品：它们只用于真正异常的场景
panic 和 recover 是 Go 提供的“最后防线”，但不是常规错误处理机制：
-
panic会立即终止当前 goroutine 的执行栈，触发所有已注册的defer -
recover只在defer函数中有效，且只能捕获同一 goroutine 内的 panic - 它们无法捕获 I/O 错误、参数校验失败等预期错误，强行用会导致控制流混乱、堆栈丢失、难以测试
使用场景极窄：
- 初始化失败（如配置加载失败、端口被占），程序无法继续运行
- 检测到严重不一致状态（如 map 并发写、nil 接口误用）
- 测试中模拟崩溃行为（仅限单元测试）
容易踩的坑：
- 在 HTTP handler 中用
panic试图统一捕获错误 → 导致整个服务 goroutine 崩溃，而非单个请求 -
recover后没做任何日志或响应，让错误静默消失 - 跨 goroutine 使用
panic（比如在go func()里 panic）→recover失效，进程直接退出
Go 2025 新提案里的 try 关键字：语法糖，不是范式反转
2025 年 5 月发布的官方错误处理提案确实引入了 try，但它不是 try/catch，也没有 catch 块：
func readFile(path string) ([]byte, error) {
file := try os.Open(path)
defer file.Close()
return try io.ReadAll(file)
}本质是：
-
try expr等价于v, err := expr; if err != nil { return ..., err } - 它只支持函数返回形如
(T, error)的表达式，不支持任意语句块 - 不改变错误是值的本质，不引入新控制流，不支持多错误类型分发（没有
catch ErrNotFound） - 仍是编译期展开的语法糖，底层仍是 if-check-return
所以它解决的是样板代码问题，不是设计哲学问题。你依然不能用它来“捕获并恢复”一个网络超时错误——你只是少写了三行 if err != nil。
自定义 error 和错误链：这才是 Go 式错误处理的真正发力点
Go 的错误能力不在“怎么抓”，而在“怎么传”和“怎么查”：
- 用
fmt.Errorf("xxx: %w", err)包装错误，保留原始错误（%w触发Unwrap()） - 用
errors.Is(err, fs.ErrNotExist)判断是否是某类错误，不依赖字符串 - 实现自己的
Error()方法，附带字段（如Code、TraceID、Stack）
常见疏漏：
- 直接
fmt.Errorf("failed to read: %v", err)→ 丢失原始 error 类型和链路，errors.Is失效 - 自定义 error 结构体没实现
Unwrap()方法，导致包装链断裂 - 日志中只打
err.Error()，不打印fmt.Sprintf("%+v", err)，看不到调用栈
真正需要花时间的地方，从来不是“怎么避免写 if”，而是“怎么让错误在跨包、跨服务、跨时间后依然可定位、可分类、可追溯”。
Go 的错误处理不难学，难的是坚持把每条错误路径都当成业务逻辑的一部分来设计。
