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