在Go多层REST API中用errs目录管理错误是否规范？有无更优方案？

你当前的错误处理方式是Go生态中比较常见的基础实践，整体方向没问题，但还有可以优化的空间，让错误处理更健壮、更具扩展性。

现有方案的优点 #

• 层间解耦：用自定义错误变量ErrUserNotFound封装底层数据库驱动错误（比如pgx.ErrNoRows），上层服务/Handler无需关心具体的数据库实现细节，只需要识别业务语义的错误类型，符合分层架构的设计原则。
• 语义清晰：自定义错误的含义明确，上层处理时能快速匹配对应业务场景，返回合适的HTTP响应。

可优化的方向与规范实现方式 #

1. 给错误添加上下文信息 #

当前的ErrUserNotFound只有固定文本，无法携带userId这类关键信息，排查问题时缺少必要线索。建议定义自定义错误类型，而非单纯使用error变量：

package errs

import "fmt"

// 通用业务错误类型，包含错误码、消息和上下文详情
type BusinessError struct {
	Code    int                    // 内部业务错误码
	Message string                 // 用户可见的错误消息
	Details map[string]interface{} // 调试用的上下文信息
}

// 实现error接口
func (e *BusinessError) Error() string {
	return e.Message
}

// 构造用户未找到错误的方法
func NewUserNotFoundError(userId int) error {
	return &BusinessError{
		Code:    1001,
		Message: "用户不存在",
		Details: map[string]interface{}{"user_id": userId},
	}
}

这样上层不仅能判断错误类型，还能提取userId等信息用于日志记录或更精准的提示。

2. 统一HTTP状态码映射逻辑 #

你当前在Handler里直接写http.StatusBadRequest，但用户未找到更适合用http.StatusNotFound（404）。如果多个Handler处理同类错误，容易出现状态码不一致的问题。可以给自定义错误添加获取HTTP状态码的方法：

func (e *BusinessError) HTTPStatus() int {
	switch e.Code {
	case 1001: // 用户未找到
		return http.StatusNotFound
	case 1002: // 参数错误
		return http.StatusBadRequest
	default:
		return http.StatusInternalServerError
	}
}

Handler里的处理逻辑会更简洁统一：

if be, ok := err.(*errs.BusinessError); ok {
	http.Error(w, be.Message, be.HTTPStatus())
} else {
	// 处理未知错误，返回通用提示
	http.Error(w, "服务器内部错误", http.StatusInternalServerError)
}

3. 保留错误链便于调试 #

当前代码直接替换了原始的数据库错误，丢失了底层错误信息，不利于深层调试。可以用Go 1.20+的errors.Join或fmt.Errorf的%w包装器保留错误链：

// 在repository层修改错误返回逻辑
if errors.Is(err, pgx.ErrNoRows) {
	// 保留原始错误，同时返回自定义业务错误
	return "", fmt.Errorf("%w: %v", errs.NewUserNotFoundError(userId), err)
}

这样上层用errors.Is(err, errs.ErrUserNotFound)依然能判断业务错误类型，同时用errors.Unwrap(err)可以拿到原始的数据库错误，方便排查底层问题。

总结 #

你的初始方案是合格的入门实践，适合小型练习项目。如果要让错误处理更专业、可维护，建议采用自定义错误类型+统一状态码映射+保留错误链的组合方式，既能保证层间解耦，又能提升调试效率和代码规范性。

内容的提问来源于stack exchange，提问作者Omegon