定义自定义error类型可提升Go语言业务逻辑校验的清晰度与可维护性，通过结构体封装错误码、消息等信息，如用户注册校验中返回ErrInvalidEmail、ErrUserExists等预定义错误，便于调用方识别处理。
在Go语言中，错误处理是通过返回error类型来实现的。为了更好地表达业务逻辑校验中的特定问题，使用自定义error能让代码更清晰、可维护性更强。下面介绍如何通过自定义error来进行业务逻辑校验。
定义自定义error类型
你可以通过定义一个结构体来封装错误信息，比如错误码、消息、发生时间等，这样不仅便于识别错误来源，还能携带额外上下文。
例如，定义一个表示用户注册失败的错误：
type BusinessError struct {
Code int
Message string
}
func (e *BusinessError) Error() string {
return e.Message
}
// 预定义一些常见的业务错误
var (
ErrInvalidEmail = &BusinessError{Code: 1001, Message: "邮箱格式不正确"}
ErrUserExists = &BusinessError{Code: 1002, Message: "用户已存在"}
ErrWeakPassword = &BusinessError{Code: 1003, Message: "密码强度不足"}
)
在业务逻辑中使用自定义error进行校验
在校验函数中，根据条件返回对应的自定义error，调用方可以根据error类型或内容做出不同处理。
立即学习“go语言免费学习笔记（深入）”；
func ValidateUserRegistration(email, password string) error {
if !isValidEmail(email) {
return ErrInvalidEmail
}
if len(password) < 6 {
return ErrWeakPassword
}
// 假设检查数据库发现用户已存在
if userExists(email) {
return ErrUserExists
}
return nil
}
// 使用示例
func RegisterUser(email, password string) {
if err := ValidateUserRegistration(email, password); err != nil {
switch e := err.(*BusinessError); e.Code {
case 1001:
log.Println("输入错误：", e.Message)
case 1002:
log.Println("注册失败：", e.Message)
case 1003:
log.Println("安全提示：", e.Message)
default:
log.Println("未知错误：", e.Message)
}
return
}
// 继续注册流程...
}
利用接口和类型断言增强灵活性
如果希望更灵活地判断错误类型，可以定义一个接口来标识业务错误，便于区分系统错误和业务错误。
type BusinessErrorInterface interface {
Error() string
Code() int
}
让*BusinessError实现该接口：
func (e *BusinessError) Code() int {
return e.Code
}
然后在处理错误时，先判断是否为业务错误：
if be, ok := err.(interface{ Code() int }); ok {
// 是业务错误，按错误码处理
switch be.Code() {
case 1001:
// 处理邮箱错误
}
}
结合errors.Is和errors.As提高兼容性
从Go 1.13开始，推荐使用errors.Is和errors.As来比较和提取error，尤其是当你包装了错误时。
如果你需要包装底层错误但仍保留原错误类型，可以用fmt.Errorf配合%w：
if userExists(email) {
return fmt.Errorf("注册失败: %w", ErrUserExists)
}
调用方可以这样判断：
if errors.Is(err, ErrUserExists) {
// 处理用户已存在的场景
}
或者提取具体类型获取更多信息：
var be *BusinessError
if errors.As(err, &be) {
log.Printf("业务错误码: %d, 消息: %s", be.Code, be.Message)
}
基本上就这些。通过定义结构化的自定义error，并结合标准库的错误包装机制，可以让Go项目的业务校验更清晰、可控。关键是统一错误模型，在团队内达成一致，避免随意返回字符串error。
