错误应在合适层级处理并清晰向上传递。Go使用error接口标准传递，每层检查错误并决定是否返回，如getUser中调用fetchFromDB，出错时用fmt.Errorf包装后向上返回。
在Go语言开发中，多层函数调用时的错误传递是一个常见且关键的问题。良好的错误处理机制不仅能提高程序的健壮性，还能让调试和维护更加高效。核心原则是：错误应在合适的层级被捕获和处理，未处理的错误应清晰地向上传递。
使用error类型进行标准错误传递
Go语言原生支持error接口，是函数间传递错误的标准方式。在多层调用中，每一层都应检查并决定是否继续向上返回错误。
示例：
func getUser(id int) (*User, error) {user, err := fetchFromDB(id)
if err != nil {
return nil, fmt.Errorf("failed to get user: %w", err)
}
return user, nil
}
func fetchFromDB(id int) (*User, error) {
// 模拟数据库查询
if id return nil, errors.New("invalid id")
}
// ...
}
这里使用%w包装错误，保留了原始错误链，便于后续通过errors.Is或errors.As进行判断。
立即学习“go语言免费学习笔记（深入）”；
避免沉默错误或过度打印
在中间层函数中，不要只打印日志而不返回错误，这会导致上层无法感知失败。
错误做法：
if err != nil {log.Printf("warning: %v", err)
return nil, nil // 错误被吞掉
}
正确做法是记录日志的同时仍返回错误，或仅在最外层处理日志与响应。
如果需要记录上下文，建议在错误包装时添加信息，而不是单独打印。
在合适层级进行错误分类与响应
通常在最外层（如HTTP handler或CLI入口）对错误进行统一处理，根据错误类型返回不同状态码或用户提示。
例如：
func handleGetUser(w http.ResponseWriter, r *http.Request) {id := parseID(r)
user, err := getUser(id)
if err != nil {
if errors.Is(err, ErrNotFound) {
http.NotFound(w, r)
return
}
http.Error(w, "Internal error", http.StatusInternalServerError)
log.Error(err) // 记录详细错误
return
}
renderJSON(w, user)
}
中间层只负责传递和增强错误信息，不决定最终响应行为。
利用defer和recover处理不可控panic
虽然Go推荐显式错误返回，但在某些场景下可能触发panic。可在关键入口使用defer+recover避免程序崩溃。
例如在HTTP服务中：
func safeHandler(fn http.HandlerFunc) http.HandlerFunc {return func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic: %v", r)
http.Error(w, "Internal Server Error", 500)
}
}()
fn(w, r)
}
}
注意：recover用于兜底，不应替代正常的错误传递流程。
基本上就这些。关键是保持错误链完整、不在中间层丢失错误、在合适位置做决策。使用fmt.Errorf包装、errors.Is/As判断，配合层级分明的结构，就能实现清晰可靠的错误传递。
