获课地址：xingkeit.top/15564/

Go 错误处理进阶：规范项目异常处理逻辑的个人思考

在接触Go语言的头两年，我对它的错误处理态度可以用“又爱又恨”来形容。爱它的直白——一个error值搞定一切，没有任何魔法；恨它的繁琐——每个函数调用后面都得跟一个if err != nil，代码里密密麻麻全是错误检查。直到我在三个不同规模的项目中经历了重构、维护和事故复盘，才逐渐理解：Go的错误处理不是设计缺陷，而是一面镜子，照出了开发者对“健壮性”的真实态度。

为什么Go的错误处理总是被误解？

很多人批评Go的if err != nil太啰嗦，我自己也曾是批评者之一。但后来我意识到一个事实：啰嗦不等于糟糕，它让你无法偷懒。在Java或Python里，你可以选择不写try-catch，让异常一路往上抛，直到某个地方被你忽略。而在Go里，每个可能出错的调用都在代码中留下了显式的痕迹——你可以选择忽略错误（用_），但那是一个刻意的、可见的决定，而不是无声的默认行为。

从个人实践看，这种设计强迫你在编写业务逻辑的同时，就思考“这一步失败了怎么办”。这不是增加认知负担，而是把思考提前到了最合适的时间点——你正在写这段代码，对上下文最清楚。

项目中的三层错误处理哲学

底层：错误即值，但要有上下文

我早期犯的错误是：到处返回err原样往上抛。结果线上出了问题，日志里只看到connection refused，根本不知道是哪个服务、哪个接口、哪个参数导致的。现在我坚持一个原则：每个错误在返回前，都要加上当时最关键的业务上下文。这不是说把整个对象序列化进去，而是加上足以定位问题的信息，比如fmt.Errorf("query user %d failed: %w", userID, err)。用%w包装原始错误，既保留了原因链，又添加了线索。

中间层：错误与业务状态的边界

在service层和repository层之间，我逐渐形成了一个习惯：区分“系统错误”和“业务错误”。数据库连接断开、网络超时、磁盘写满——这些是系统错误，应该向上传播，最终由顶层决定重试或降级。而“用户不存在”、“订单已支付”、“库存不足”这些是业务错误，它们不应该被当作error链条传播，而应该作为业务结果的一部分返回。

我见过太多项目把业务错误也用error返回，导致上层不得不做字符串匹配或类型断言来判断具体原因。更好的做法是定义一个明确的业务状态结构体，或者用哨兵错误配合errors.Is。这听起来是小事，但在大型项目中，这是代码可维护性的分水岭。

顶层：优雅降级，而不是静默吞噬

在HTTP handler或RPC接口的顶层，我犯过最严重的错误是“为了不报错而忽略错误”。比如用户查询失败，直接返回空列表而不是报错——结果用户以为功能正常，但数据丢了。现在我遵循的原则是：顶层不吞噬错误，但可以转换错误。给用户返回一个友好的错误消息，后台记录完整的错误堆栈；如果是非关键路径（比如推荐算法失败），可以降级返回默认内容，但必须在日志中明确标记。静默失败是最危险的错误处理方式。

进阶规范：让错误处理可读、可维护

经过几个项目的迭代，我总结了一套团队内自用的规范：

第一，错误变量命名统一。包级公开的哨兵错误用ErrXxx（首字母大写），内部用的用errXxx。不要用ErrorXxx或E_XXX，保持项目内一致。

第二，错误包装有规矩。底层往上每层最多包装一次上下文，避免重复或过于冗长的信息。同时，不要暴露内部敏感信息给客户端——数据库查询语句、内部IP地址这些，只在日志里打印，返回给用户的错误信息要经过清洗。

第三，错误日志分层打印。底层只记录Debug级别的详细错误，中层记录Warning级别的业务异常，顶层根据决策记录Error级别并附加请求ID。同一个错误不要在三层都打日志，否则你会得到一个噪音满满的日志系统。

我的最终感悟

用Go写代码五年后，我反而开始珍惜那个被无数人吐槽的if err != nil。它不是噪音，而是一种诚实的契约：代码的每一行都可能失败，而你要对每一行负责。当新手问我Go错误处理的最佳实践时，我会说：先别急着找框架或技巧，认真思考你的每一步操作失败后应该做什么——是重试、降级、返回兜底数据，还是直接报错。想清楚这些，你的Go项目已经比90%的项目更健壮了。