go中panic仅用于不可恢复的程序异常，业务错误必须用error返回并显式处理；重试需控制次数、超时和退避策略；i/o操作须传入context.context；错误应结构化记录并分类观测。
Go 中 panic 和 error 的分工必须明确
Go 不支持 try/catch，panic 仅用于真正不可恢复的程序异常（如空指针解引用、切片越界），而非业务错误。所有可预期的失败——比如文件不存在、网络超时、JSON 解析失败——都该用 error 类型返回并由调用方显式处理。
常见错误是把 HTTP 请求失败、数据库查询为空等场景用 panic 处理，这会导致服务意外崩溃。正确做法是：只要函数签名含 error 返回值，就默认调用方会检查它；不检查即埋雷。
- HTTP 客户端调用后必须检查
resp, err := client.Do(req)中的err，不能只看resp.StatusCode - 使用
os.Open后，即使file != nil，也要先判断err != nil再操作文件句柄 - 自定义错误建议用
fmt.Errorf("failed to parse config: %w", err)包装，保留原始调用链
重试机制要控制退出条件和退避策略
对临时性失败（如网络抖动、DB 连接池满）加重试是常见容错手段，但裸写 for 循环 + time.Sleep 容易失控。关键点不在“重试”，而在“何时停止”和“怎么等”。
推荐用 backoff.Retry（来自 github.com/cenkalti/backoff/v4）或自己封装带最大次数、最大耗时、指数退避的逻辑。硬编码 time.Sleep(100 * time.Millisecond) 在高并发下可能引发雪崩。
立即学习“go语言免费学习笔记（深入）”；
- 单次重试间隔应随失败次数增长，例如从 100ms → 200ms → 400ms，避免打爆下游
- 必须设总超时（如
context.WithTimeout(ctx, 5*time.Second)），防止一个请求卡住整个 goroutine - 某些错误不该重试，比如
sql.ErrNoRows或os.IsNotExist(err)，需提前判断跳过
使用 context.Context 传递取消与截止时间
Go 的容错不是靠捕获异常，而是靠主动协作：上游通过 context.Context 告知下游“你只有 3 秒，超时就停”。所有 I/O 操作（HTTP、DB、RPC）都应接受 ctx 参数，并在 ctx.Done() 触发时及时释放资源。
漏传 ctx 是最隐蔽的容错漏洞。比如一个 HTTP handler 启动了 goroutine 去异步发日志，但没把 ctx 传进去，那么 handler 已返回、连接已关闭，goroutine 还在傻等响应，最终泄漏。
- 调用
http.NewRequestWithContext(ctx, ...)替代http.NewRequest - 数据库查询用
db.QueryContext(ctx, ...)而非db.Query - 自定义函数若含阻塞操作（如 channel receive、time.Sleep），也应接收
ctx并监听ctx.Done()
错误分类与可观测性不能只靠 log.Print
生产环境出问题时，“打印了 error”不等于“能定位问题”。真正的容错设计需要区分错误类型、记录上下文、暴露指标。比如同一个 io.EOF，在读配置文件时是严重错误，在读 HTTP body 时可能是正常结束。
建议用结构化日志（如 zerolog 或 zap）记录 error 字段，并附加 trace ID、操作名、输入参数哈希等。同时用 prometheus.CounterVec 统计不同错误码出现频次。
- 避免
log.Printf("failed: %v", err)—— 丢失堆栈、无字段、难聚合 - 对第三方库返回的 error，用
errors.As(err, &target)或errors.Is(err, target)做类型判断，而不是字符串匹配 - 内部服务间调用，应在 error 中嵌入状态码（如
errors.Join(err, errors.New("status=503"))），方便网关统一熔断
实际落地中最容易被忽略的是：错误处理逻辑本身也可能出错（比如日志写入失败、监控上报超时）。这些次要路径如果再 panic，就会掩盖主路径的真实问题。容错不是加更多 if，而是让每条失败路径都安静、可追溯、不连锁崩溃。
