Go语言错误处理，如何构建三层防线？说实话，这是一个老生常谈的问题，但咱就是说每次聊到这个话题，总有人会跳出来说“加个语法糖不就好了？”，哈哈，问题真的有那么简单吗？

你写了一万遍 if err != nil，但你有没有想过：这个错误该往哪层抛？该对谁暴露？该返回什么 HTTP 状态码？hen多时候，咱就是随手一写，管它呢，反正Neng跑就行。

但实际情况是hen多 Go 项目根本没有错误分层。底层 infra 错误裸奔到 HTTP 响应，业务错误和系统错误混为一谈，panic 被当成快捷 throw。语法糖加不加，跟这些问题毫无关系。

解决方案不复杂。三层就够了：Handler 层 → Service 层 → Infra 层。每一层有自己的错误类型，只向上暴露对上一层有意义的错误。

Infra 层是物理层，Service 层是传输层，Handler 层是应用层。物理层故障不应该以原始形态暴露给应用层。当然Go 的错误分层是约定而非强制，这要求团队的自律和 code review。

// infra/errors.go type InfraError struct { Op string // 操作名，如 "db.Query" Err error // 原始错误，仅在日志中使用 } func Error string { return e.Op + ": " + e.Err.Error } func Unwrap error { return e.Err }

// service/errors.go type ServiceError struct { Code string // 业务错误码，如 "USER_NOT_FOUND" Message string // 面向用户的消息 Err error // 内部错误，不暴露给外层 } func Error string { return e.Code + ": " + e.Message } func Unwrap error { return e.Err }

panic 不是不Neng用，而是只有极少数场景才该用。判断标准hen简单：Ru果程序继续执行会产生比崩溃geng严重的后果，panic 就是合理的。

程序启动时配置缺失，跑下去也没有意义。没有数据库连接，没有缓存地址，所有请求dou会失败。这时候 panic 是合理的，因为这是真正的不可恢复错误。

用 panic Zuo"快速返回"，再在 handler 顶层 recover 一下。kan起来hen优雅，实际上是灾难。因为 recover 之后你hen难判断 panic 的来源，是数据库超时？是 nil 指针？还是除零错误？没有类型信息，你只Neng猜。

Ru果你有一个Yi经跑了一两年的项目，到处是 err.Error 写到 HTTP 响应、panic Zuo快速返回、错误没有分层的代码，你不需要重写，Ke以渐进式改造。

关键原则：每一步改造dou应该让系统比改造前geng好，而不是让系统处于一个"改了一半"的不稳定状态。

. 定义 InfraError 和 ServiceError 类型，不动现有逻辑。

. 改 handler 层的错误输出，确保不泄露敏感信息。

. 改 service 层的错误转换，确保语义正确。

. 改 infra 层的错误包装，确保操作标签完整。

Go 社区吵了十年的错误处理问题，吵偏了方向。语法派声量Zui大，提案Zui多，成果为零。语义派的成绩单是 Go <某个版本> 的错误包装机制和 <某个版本> 的 errors.Join，实打实的语言改进。架构派的讨论散落在各个项目的实践中，没有形成社区级的共识和统一方案。

if err != nil 不是问题，不知道这个 error 该往哪层放才是问题。三层错误分层、panic 的正确使用场景、Go <某个版本> 以来的标准库新Neng力，这些dou不需要改语言，只需要改认知。

. 接口实现的编译期检查

var _ http.Handler = // 编译期检查

. 程序初始化失败

func init { cfg, err := config.Load if err != nil { panic) } }

. 数据结构约束违反

func Next byte { if r.count == 0 { panic } // ... }

. Handler 层永远不把 error 的 .Error 输出写到 HTTP 响应里。响应里只放 Message 字段和 Code 字段，这两个字段是在 Service 层精心设计的安全信息。

. 使用 errors.Join 处理批量操作中的部分失败，保留类型信息。

func BatchInsert error { var errs error for _, u := range users { if err := insert; err != nil { errs = append) } } return errors.Join // nil if no errors }

// errors.Join：保留类型信息 joined := errors.Join errors.Is // true errors.Is // true // 字符串拼接：类型信息全丢 manual := fmt.Errorf errors.Is // false errors.Is // false

"kan情况"这一行需要展开说。数据结构约束违反的 panic 是否应该替换，取决于两点：一是这个约束是否在测试中Neng被覆盖，二是这个 panic 发生时的后果。Ru果测试Neng覆盖，说明 panic 只会在测试阶段触发，改成 error 没有实际区别。Ru果测试不Neng覆盖，panic 发生时你需要完整的堆栈信息来定位问题，这时候保留 panic geng有价值。

...