17370845950

Go中业务逻辑错误应通过类型化错误和分层设计区分于系统错误：BusinessError用于可预期的业务规则失败（如余额不足），返回4xx响应；系统错误（如DB连接中断）保留错误链、记录日志并返回5xx，触发告警。

在 Go 中处理业务逻辑错误，关键不是“捕获所有 panic”，而是通过类型化错误和分层设计，让逻辑错误可识别、可响应、可追踪，同时与系统错误（如网络超时、磁盘满、DB 连接失败）明确区隔。

用自定义错误类型区分逻辑错误

逻辑错误是业务规则不满足导致的预期内失败，比如“余额不足”“订单已取消”“手机号格式错误”。它们不该触发告警，也不该重试，而应直接返回给调用方并引导用户修正。

推荐定义带状态码和业务上下文的错误类型：

• 定义 BusinessError 结构体，包含 Code（如 ErrInsufficientBalance = 4001）、Message、Details（如 map[string]interface{}{"available": 12.5, "required": 100.0}）
• 实现 Error() 方法返回用户友好的提示（如 “余额不足，请充值”），而非技术细节
• 避免用字符串拼接或 errors.New 创建逻辑错误——无法结构化识别

系统错误走标准 error + 外部可观测性链路

系统错误是程序外部异常，比如数据库连接中断、HTTP 请求超时、JSON 解析失败。它们不可预测、需监控、可能自动恢复。

这类错误应：

• 保留原始 error（如 sql.ErrNoRows、context.DeadlineExceeded），必要时用 fmt.Errorf("db query failed: %w", err) 包装，保持错误链
• 在 infra 层（如 repository、client）统一记录日志（含 traceID、error type、stack），但不暴露给上层业务逻辑
• 由网关或 API 层统一转换为 5xx 响应，并触发告警；绝不把 "dial tcp: i/o timeout" 直接返回给前端

在 handler/service/repository 分层中各司其职

错误不应“一路向上 panic”，而应在合适层级拦截和转化：

• Repository 层：只返回原始系统错误（如 DB error）或 nil；不处理“用户不存在”这类逻辑判断——那是 service 的事
• Service 层：接收 repository 返回值后，做业务校验。校验失败 → 返回 *BusinessError；遇到 repository 错误 → 记录日志 + 返回原 error 或封装为系统错误（如 ErrStorageUnavailable）
• Handler 层：检查返回 error 类型——是 *BusinessError 则写入 4xx 响应；否则视为系统错误，返回 500 并上报监控

用 errors.As 和 errors.Is 实现可靠判断

运行时识别错误类型，避免用字符串匹配或反射：

• 判断是否为某类逻辑错误：if errors.Is(err, ErrOrderAlreadyCancelled) { ... }
• 提取具体业务错误信息：var be *BusinessError; if errors.As(err, &be) { log.Warn("business fail", "code", be.Code, "details", be.Details) }
• 在 middleware 或全局 ErrorHandler 中集中处理，避免每个 handler 写重复判断逻辑

不复杂但容易忽略：逻辑错误不是“要掩盖的缺陷”，而是业务流程的正常分支；系统错误不是“要吞掉的噪音”，而是稳定性的重要信号。区分清楚，才能让日志可读、告警有效、用户体验可控。