本文永久链接 – https://tonybai.com/2023/06/18/go-package-design-guide

1. Go包的认知

1.1 Go包是基本功能单元

我们知道Go包是Go编程语言中的一个重要概念，它是一组相关的Go源代码文件。并且，在Go中，每个Go源文件都必须属于一个包。

Go包是一个逻辑上独立的单元，是Go的基本功能单元，用来做功能边界的划分。这些基本功能单元的累加就构成了Go应用，因此Go应用的本质就是一组Go包的集合。

Go包这种功能独立的单元为Go开发者提供了“封装”和复用的便利。在Go中，Go包也是代码复用的基本单元，被用来管理和组织代码，Go项目的结构布局本质上就是安排Go包的位置，使得代码更易于维护和重用。

1.2 Go包是基本编译单元

Go包还是编译时的最小单位。也就是说，Go编译器编译代码时会以包为单位进行编译，而不是以文件为单位。这意味着一个包中的所有源文件都将被编译成一个单独的目标文件，而不是多个目标文件。

使用包而不是文件作为编译单元，有助于提高编译效率和管理依赖关系。

注：编译速度快是包这种设计“先进性”的一个表现，即便每次编译都是从零开始。Go编译速度快的几个原因与以包作为编译单元是密不可分的，具体体现在Go源文件在开头处显式地列出所有依赖包，编译器不必读取整个文件就可确定依赖包列表；Go包之间不能存在循环依赖，由于无环，包可以被单独编译，也可以并行编译；已编译的Go包的目标文件中记录了其所依赖包的导出符号信息。Go编译器在读取该目标文件时不需进一步读取其依赖包的目标文件。

1.3 Go包是基本设计单元

这个世界越来越复杂，软件系统同样变得日益复杂。无论你是什么编程语言的开发者，我们要面对的都是如何驯服这种复杂性。到目前为止，我们驯服这种复杂性的思路还很初级，无非是对复杂性进行分解、分解、分解，并按照我们更容易理解的方式重新组合。

Go包是基本功能单元，对于Go开发者，我们要将复杂性分解为一个个包，然后以一种合理的方式将包组合在一起以实现我们要的系统，因此Go包也是我们面对一个系统时的基本设计单元。我们不仅要设计每个包肩负的职责，还要设计包与包之间的关系。

因此，Go系统设计就是面向包进行设计。

接下来，我们就来看看Go包的设计思路。

2. Go包设计思路

即便你没写过Go程序，作为程序员你也应该知道“高内聚，低耦合”这个原则在软件系统设计中的分量。这里我们就以这个原则作为“抓手”来展开看看Go包的设计思路。

高内聚, 低耦合这个顶层原则，适用于所有编程语言的系统设计。但落到Go包设计上面，具体如何体现高内聚与低耦合呢？我们继续往下看。

2.1 功能选桶：自然内聚

面对一个复杂系统，我们通常会做一些系统分析，比如用领域驱动设计的方式从需求中挖掘出一堆术语、事件、命令等(即便你不懂领域设计的纯正方法，你的实际操作过程也或多或少与领域设计的内容重叠)。之后，通常会分层、划分服务，每个服务又要划分模块或包。

在服务这一层次上哪些功能放到哪个包里呢？这个过程我称之为“功能选桶”。

这让我想到了和孩子一起学习动物分类时的书中题目：

有这样一组动物：老虎、狮子、海马、大雁、熊猫、黄鹂、鲸鱼，这些动物能分为哪几个类别呢?

一个稍稍被启蒙了的孩子都会给出这样的分类：

陆地动物：老虎、狮子、熊猫
海洋动物：海马、鲸鱼
天空动物：大雁、黄鹂

而另外一个稍有一些生物学入门知识的大点的孩子可能也会给出下面的分类：

哺乳动物：老虎、狮子、熊猫、鲸鱼
卵生动物：海马、大雁、黄鹂

无论哪种，这些分类都是基于动物行为特征的自然结合。第一种似乎更直观自然，第二种则需要有更“专业”的知识（领域知识）。Go包的“功能选桶”其实是一个道理，相关功能自然结合到一个包中，保证这个包的内聚性。

比如下面有几个功能函数：Add、Subtract、Multiply、Divide、Sum、Average、Histogram，我们如何为这几个函数选桶呢？

一种不那么内聚的作法是将上述所有函数都放入math包；而更自然内聚一些的作法则是将Add、Subtract、Multiply、Divide放入math包，而将Sum、Average、Histogram等放入stats包(statistics，统计学)。

在功能选桶过程中，越符合常人思维，就越自然，可读性和可理解性大概率就越好。

2.2 包间关系：最小耦合

功能选桶之后，我们再来看包与包之间的关系，通常我们这种关系称为耦合。

用白话来理解耦合就是：当a变化时，b受到影响并随之变化，则说b与a之间存在耦合，即b依赖a。a是引发b变化的一个原因。

程序员都知道：一种理想的耦合情况是正交，即你变你自变，我岿然不动。但现实中这很难达到，我们应该追求的是尽可能地降低包与包间的耦合。

在包依赖层面，Go强制要求不能存在循环依赖，即Go包之间的耦合一定是有向无环的，这一定层度上也能帮助Go包之间降低耦合。

要降低包与包之间的耦合，我们首先要了解Go包间的最低耦合关系是什么呢？

在代码层面最低的耦合是接口耦合，在Go中，接口的实现是隐式的，即a包实现b包中定义的接口时是不需要显式导入b包的，我们可以在c包中完成对a包与b包的组装，这样c包依赖a包和b包，但a包与b包之间没有任何耦合。

那么负责组装a包与b包的c包能否在代码层面消除掉对a和b的依赖呢？这个就很难了。不过我们可以使用依赖注入技术来消除在代码层面手动基于依赖进行初始化或创建时的复杂性，不过依赖注入技术也是有“门槛”的，它会让你的代码不那么straightforward，代码的可读性和可理解性会下降。

注：个人觉得：依赖注入在Go中并非是一种惯用法。Google开源了像wire这样的依赖注入框架(通过代码生成而实现的编译期依赖注入)，更多是为了解决掉内部大型Go项目初始化时各种创建动作的复杂性。

我们可以参考软件界用于降低代码耦合的原则，比如由Robert C. Martin（通常被称为“Uncle Bob”）在《敏捷软件开发》一书中提出的旨在帮助开发人员设计更加灵活、可扩展和可维护的软件系统的SOLID敏捷设计原则，这些原则如何应用在Go上呢，或者在Go中如何体现呢，我们接下来就来看一下。

注：“敏捷设计是一个过程，而不是一次事件。它是一个持续应用原则、模式以及实践来改进软件结构和可读性的过程。它致力于保持系统的设计在任何时间都尽可能的简单、整洁和富有表现力。” – 《敏捷软件开发》

2.3 应用SOLID设计原则

2.3.1 单一职责原则（SRP）

对于一个类而言，应该仅有一个原因会引起它的变化。在SRP的语境中，我们把职责定义为“变化的原因”(a reason for change)。如果你有超过一个的动机去改变一个类，那么这个类就具有多种职责。- 《敏捷软件开发》

就像Uncle Bob在书中说的那样：“如果你有超过一个的动机去改变一个类，那么这个类就具有多种职责。有时，我们很难注意到这一点。我们习惯于以组(group)的形式去考虑职责”。

在Go包这一层次上，SRP更多体现在功能内聚上，就像前面举的math包和stats包的例子。

再比如我们有一个图形库，它可以绘制不同类型的图形，如矩形、圆形、三角形等。我们可能会定义一个graph包，里面定义了Graphics类型，它具有Draw方法，用于绘制图形。在不遵循SRP的情况下，graph包Graphics类型可能会包含绘制各种类型图形的代码，这会导致类不仅包含多个职责，而且功能不够内聚。

在遵循SRP的情况下，我们可以在graph包中定义Graphics接口，该接口具有Draw方法，然后在rectangle、circle、triangle包中分别定义Graphics接口的实现：Rectangle类型、Circle类型与Triangle类型：

graph/
    - graph.go // 定义Graphics接口
    - rectangle/
        - rectangle.go // 定义Rectangle类型和其Draw方法
    - circle/
        - circle.go // 定义Circle类型和其Draw方法
    - triangle/
        - triangle.go // 定义Triangle类型和其Draw方法

这样，每个包都只负责一个图形类型，职责更加单一，也更容易维护和扩展。

2.3.2 开放-关闭原则(OCP)

软件实体（类、模块、方法等）应该对扩展开放，但是对修改关闭。- 《敏捷软件开发》

还以上面的graph等包为例，OCP原则可以体现在两方面：

• 扩展Graphics接口的实现

我们无法修改graph.go中的Graphics接口，但如果你要添加一个square包，定义Square类型并实现Draw方法，那么我们可以在graph包下面添加一个square包，这个包和circle等包位于同等位置，都实现了graph包的Draw方法。

• 基于Graphics接口的组合

我们无法修改graph.go中的Graphics接口，但是我们可以基于graph.Graphics接口去组合出其他具有更多职责的接口或非接口类型，就像io包中的Reader、Writer接口被组合到ReaderCloser、ReadWriteCloser中一样。

OCP原则的关键是抽象，在Go中建立包与包之间关系抽象的最佳方法就是建立接口类型。前面说过，通过接口的耦合是最低的包间耦合，因此采用OCP原则对于降低包间耦合具有重要意义。

不过，Bob大叔在书中也说了：“遵循OCP的代价也是昂贵的。创建恰当的抽象是要花费时间和精力的。那些抽象也增加了软件设计的复杂性，开发人员有能力处理的抽象数量是有限的”。OCP原则的应用应该被限定在最可能发生的变化上。

2.3.3 里氏替换原则(LSP)

对于里氏替换原则(LSP)，可以如此解释：子类型(subtype)必须能够替换掉它们的基类(base type)。- 《敏捷软件开发》

Bob大叔在讲解LSP原则时使用的语言是C++和Java，对于这两种静态类型的OO语言来说，支持抽象和多态的关键机制之一是继承(inheritance)。也只有在继承的概念之上，采用基类和子类之分。

不过Go并非传统意义上的OO语言，它没有继承，没有类型层次体系。即便没有这些，Go也不乏抽象表达能力，最直接的就是接口这个行为的集合。

这样里氏替换原则(LSP)在Go中就可以如此解释：接口I的所有实现都是可以相互替代的，因为它们履行了同样的契约。

2.3.4 接口隔离原则(ISP)

客户端程序不应该被迫依赖于它们不需要的方法。- 《敏捷软件开发》

这个在体现Go包与包关系层面不是那么明显，方法已经告诉你这种耦合是接口耦合，但究竟用的是什么样的接口呢？“胖接口”，不是！我们需要刚刚好，不多不少的接口。

来看一个例子：我们有如下一些接口定义：

type Printer interface {
    Print()
}

type Scanner interface {
    Scan()
}

type PrintSleeper interface {
    Printer
    Sleep()
}

type PrintScanSleeper interface {
    Printer
    Scanner
    Sleep()
}

现在我们要实现一个打印机打印的API，我们最初的设计是：

func Print(p PrintScanSleeper, data []byte) error {
}

在这个设计中，Print函数依赖的是PrintScanSleeper，这意味着传入的合法参数的类型必须要实现Print、Scan和Sleep三个方法，但我们的函数只是为了实现打印，它不需要调用Scanner的Scan方法，根据ISP原则，我们不应该强迫Print函数依赖它们本不需要的方法，于是第二版设计如下：

func Print(p Printer, data []byte) error {
}

这似乎无懈可击。但常识告诉我们，每次打印结束后，都需要让打印机休眠，那么显然仅依赖Printer接口又缺少了点东西，那么最终版的设计如下：

func Print(p PrintSleeper, data []byte) error {
}

对ISP原则的白话阐述就是：“不多不少，刚刚好”！

2.3.5 依赖倒置原则(DIP)

高层次的模块不应该依赖低层次的模块。两者都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。- 《敏捷软件开发》

如果你的代码符合上面的几条原则的话，那么到这里，你的代码很大可能也是符合DIP原则的。

一提到“依赖抽象”，大家肯定想到的还是接口。在Go中，接口是抽象的主要代名词。

在包与包的关系层面上，DIP原则表现为：高层次包依赖接口，低层次的包实现接口，如下图：

因此，在同等条件下，采用DIP原则设计良好的Go程序的包导入图应该是宽而平的，而不是高而窄的：

3. 单包设计

说完了包的内聚与包间关系的耦合后，我们最后将精力聚焦在单包的设计上面，看看一个Go包在设计方面有哪些值得借鉴的tips。

3.1 包名

我们在引用某个包的导出标识符时使用的是：

pkgname.XXX

由此可见包名的重要性，它可以理解为一个包的API的重要组成部分，因此包设计的第一步就是要为包起个好名字。

给Go包起名字首先要注意简单达意，比如标准库的fmt、io、os等，并且包名按惯例应该与其目录名一致；

其次，同一工程内部包名最好是唯一的，避免工程内部出现名字碰撞；

最后，如果为了简洁而失去了包名的内聚性的内涵(功能和作用)，比如utils、common这些名字基本无法表达包究竟担负的职责，那么莫不如将包名加长一些，点缀上能达意的单词，比如printutil而不仅仅是util。

3.2 最小暴露表面积

在单包设计时，要考虑最小暴露表面积，指定是应该尽可能减少包暴露给外部的接口和实现，只暴露必要的最小接口，以提高代码的安全性和可维护性。同时，从用户角度来看，只暴露必要信息的包看起来更易用。

具体来说，可以分为如下几点：

• 使用接口建立抽象

在设计包时，应该使用接口来建立抽象，而不是直接暴露实现。这样可以将实现细节隐藏起来，只暴露接口，从而提高代码的安全性和稳定性。

• 最小化暴露的接口

即便是暴露接口，在设计包时，也应该尽量减少暴露给外部的接口数量。只有必要的接口应该暴露出来，从而提高代码的安全性和稳定性。

• 使用非导出方法和变量封装实现细节

在设计包时，应该使用非导出方法和变量来封装包内部的实现细节，只暴露公共接口。这样可以将实现细节隐藏起来，避免外部代码直接依赖包内部的实现，从而提高代码的可维护性和灵活性。

• 最小化暴露的实现

在设计包时，应该尽量减少暴露给外部的实现数量。只有必要的实现应该暴露出来，而不是将所有实现都暴露出去。这样可以避免外部代码直接依赖包内部的实现，从而提高代码的可维护性和灵活性。

3.3 避免包级变量带来的包级状态

Go没有显式的全局变量，但包的导出变量本质上就是全局变量。在《聊聊Go语言的全局变量》一文中我们详细说明了全局变量的不足，因此应避免这类充当全局变量的包级变量的暴露。

3.4 main包应尽可能简洁

在Go中，main包是特殊的包，用于定义程序的入口函数main。在Go中，main函数应该尽可能简洁，它应该只负责装配其他包，调用其他函数或模块，不应该包含过多的代码逻辑。这样可以提高代码的可读性和可维护性。如果要对main函数进行单测的话，那么可以将main函数的逻辑放置到另外一个函数中，比如run，然后对run函数进行详尽的测试。

3.5 接口类型定义应放在与使用者更近的地方

Go接口是隐式实现的，意味着其实现者不需要显式告知实现了该接口，实现者所在包也无需导入接口定义所在的包。

这样一来，将接口类型定义放在与使用者更近的地方，可以使代码更加清晰和易于理解。使用者可以直接看到接口类型定义，了解接口类型的作用和使用方法。但注意：这并非是绝对的规则。

有些接口的实现者喜欢在自己的包中放置var i some_interface = (*T)(nil) ，以利用编译器的静态检查断言自己定义的类型*T实现了接口some_interface，这样一来实际上是显式宣告了在实现者和接口包之间关系，属于“增加耦合”的步骤。

如果接口类型在同一个包里提供了默认实现，那么这么做无可厚非，比如io包。

4. 小结

下面对本文内容做个小结：

• Go包是Go程序设计的基本单元，分解复杂性的基本单位。
• Go包应被设计为高内聚，关注同一职责，并尽量与其他包低耦合。
• 在设计Go包时，可以按照功能选桶，根据自然内聚思维来划分包，并遵循最小耦合原则减少包间依赖。
• 可以运用SOLID设计原则优化Go包间的关系:
  • SRP：每个包都有单一的职责，具有高内聚。
  • OCP：包对扩展开放，对修改关闭。
  • LSP：接口的实现是互相替换的。
  • ISP：接口将只暴露必要方法。
  • DIP：高层包和低层包都依赖抽象，细节应依赖抽象。
• 在单包设计时应考虑最小暴露表面积，只暴露必要的接口和实现。
• 避免用包级变量带来的全局状态。main包应简洁。
• 接口类型定义最好放在使用者更近的地方。

希望能为大家提供参考！如果有不正确或遗漏的地方，欢迎指出，共同进步。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2023/05/14/a-guide-of-using-go-error-chain

0. Go错误处理简要回顾

Go是一种非常强调错误处理的编程语言。在Go中，错误被表示为实现了error接口的类型的值，error接口只有一个方法：

type error interface {
    Error() string
}

这个接口的引入使得Go程序可以以一致和符合惯用法的方式进行错误处理。

在所有编程语言中，错误处理的挑战之一都是能提供足够的错误上下文信息，以帮助开发人员诊断问题，同时又可以避免开发人员淹没在不必要的细节中。在Go中，这一挑战目前是通过使用错误链(error chain)来解决的。

注：Go官方用户调查结果表明，Go社区对Go错误处理机制改进的期望还是很高的。这对Go核心团队而言，依然是一个不小的挑战。好在Go 1.18泛型落地，随着Go泛型的逐渐成熟，更优雅的错误处理方案有可能会在不远的将来浮出水面。

错误链是一种将一个错误包裹在另一个错误中的技术，以提供关于错误的额外的上下文。当错误通过多层代码传播时，这种技术特别有用，每层代码都会为错误信息添加自己的上下文。

不过，最初Go的错误处理机制是不支持错误链的，Go对错误链的支持和完善是在Go 1.13版本中才开始的事情。

众所周知，在Go中，错误处理通常使用if err != nil的惯用法来完成。当一个函数返回一个错误时，调用代码会检查该错误是否为nil。如果错误不是nil，通常会被打印到日志中或返回给调用者。

例如，看下面这个读取文件的函数：

func readFile(filename string) ([]byte, error) {
    data, err := os.ReadFile(filename)
    if err != nil {
        return nil, err
    }
    return data, nil
}

在这段代码中，os.ReadFile()如果读取文件失败，会返回一个错误。如果发生这种情况，readFile函数会将错误返回给它的调用者。Go的这种基本的错误处理机制简单有效好理解，但它也有自己的局限性。其中一个主要的限制是错误信息可能是模糊的。当一个错误在多层代码中传播时，开发人员可能很难确定错误的真实来源和原因。 我们看一下下面这段代码：

func processFile(filename string) error {
    data, err := readFile(filename)
    if err != nil {
        return fmt.Errorf("can not read file: %s", filename)
    }
    // process the file data...
    return nil
}

在这个例子中，如果processFile因readFile失败而返回一个错误，错误信息将只表明该文件无法被读取，它不会提供任何关于造成错误的原因或错误发生地点的准确信息。

Go基本错误处理的另一个约束是在处理错误时，错误的上下文可能会丢失。尤其是当一个错误通过多层代码时，某一层可能会忽略收到的错误信息，而是构造自己的错误信息并返回给调用者，这样最初的错误上下文就会在错误的传递过程中丢失了，这不利于问题的快速诊断。

那么，我们如何解决这些限制呢？下面我们就来探讨一下错误链是如何如何帮助Go开发人员解决这些限制问题的。

1. 错误包装(error wrapping)与错误链

为了解决基本错误处理的局限性，Go在1.13版本中提供了Unwrap接口和fmt.Errorf的%w的格式化动词，用于构建可以包裹(wrap)其他错误的错误以及从一个包裹了其他错误的错误中判断是否有某个指定错误，并从中提取错误信息。

fmt.Errorf是最常用的用于包裹错误的函数，它接收一个现有的错误，并将其包装在一个新的错误中，并可以附着更多的错误上下文信息。

例如，改造一下上面的示例代码：

func processFile(filename string) error {
    data, err := readFile(filename)
    if err != nil {
        return fmt.Errorf("failed to read file: %w", err)
    }
    // process the file data...
    return nil
}

在这段代码中，fmt.Errorf通过%w创建了一个新的错误，新错误包裹(wrap)了原来的错误，并附加了一些错误上下文信息(failed to read file)。这个新的错误可以在调用堆栈中传播并提供更多关于这个错误的上下文。

为了从错误链中检索原始错误，Go在errors包中提供了Is、As和Unwrap()函数。Is和As函数用于判定某个error是否存在于错误链中，Unwrap这个函数返回错误链中的下一个直接错误。

下面是一个完整的例子：

func readFile(filename string) ([]byte, error) {
    data, err := os.ReadFile(filename)
    if err != nil {
        return nil, err
    }
    return data, nil
}

func processFile(filename string) error {
    data, err := readFile(filename)
    if err != nil {
        return fmt.Errorf("failed to read file: %w", err)
    }
    fmt.Println(string(data))
    return nil
}

func main() {
    err := processFile("1.txt")
    if err != nil {
        fmt.Println(err)
        fmt.Println(errors.Is(err, os.ErrNotExist))
        err = errors.Unwrap(err)
        fmt.Println(err)
        err = errors.Unwrap(err)
        fmt.Println(err)
        return
    }
}

运行这个程序(前提：1.txt文件并不存在)，结果如下：

$go run demo1.go
failed to read file: open 1.txt: no such file or directory
true
open 1.txt: no such file or directory
no such file or directory

该示例中错误的wrap和unwrap关系如下图：

像这种由错误逐个包裹而形成的链式结构(如下图)，我们称之为错误链。

接下来，我们再来详细说一下Go错误链的使用。

2. Go中错误链的使用

2.1 如何创建错误链

就像前面提到的，我们通过包裹错误来创建错误链。

目前Go标准库中提供的用于wrap error的API有fmt.Errorf和errors.Join。fmt.Errorf最常用，在上面的示例中我们演示过了。errors.Join用于将一组errors wrap为一个error。

fmt.Errorf也支持通过多个%w一次打包多个error，下面是一个完整的例子：

func main() {
    err1 := errors.New("error1")
    err2 := errors.New("error2")
    err3 := errors.New("error3")

    err := fmt.Errorf("wrap multiple error: %w, %w, %w", err1, err2, err3)
    fmt.Println(err)
    e, ok := err.(interface{ Unwrap() []error })
    if !ok {
        fmt.Println("not imple Unwrap []error")
        return
    }
    fmt.Println(e.Unwrap())
}

示例运行输出如下：

wrap multiple error: error1, error2, error3
[error1 error2 error3]

我们看到，通过fmt.Errorf一次wrap的多个error在String化后，是在一行输出的。这点与errors.Join的有所不同。下面是用errors.Join一次打包多个error的示例：

func main() {
    err1 := errors.New("error1")
    err2 := errors.New("error2")
    err3 := errors.New("error3")

    err := errors.Join(err1, err2, err3)
    fmt.Println(err)
    errs, ok := err.(interface{ Unwrap() []error })
    if !ok {
        fmt.Println("not imple Unwrap []error")
        return
    }
    fmt.Println(errs.Unwrap())
}

这个示例输出如下：

$go run demo2.go
error1
error2
error3
[error1 error2 error3]

我们看到，通过errors.Join一次wrap的多个error在String化后，每个错误单独占一行。

如果对上面的输出格式都不满意，那么你还可以自定义Error类型，只要至少实现了String() string和Unwrap() error 或Unwrap() []error即可。

2.2 判定某个错误是否在错误链中

前面提到过errors包提供了Is和As函数来判断某个错误是否在错误链中，对于一次wrap多个error值的情况，errors.Is和As也都按预期可用。

2.3 获取错误链中特定错误的上下文信息

有些时候，我们需要从错误链上获取某个特定错误的上下文信息，通过Go标准库可以至少有两种实现方式：

第一种：通过errors.Unwrap函数来逐一unwrap错误链中的错误。

由于不确定错误链上的error个数以及每个error的特征，这种方式十分适合用来获取root cause error，即错误链中最后面的一个error。下面是一个示例：

func rootCause(err error) error {
    for {
        e, ok := err.(interface{ Unwrap() error })
        if !ok {
            return err
        }
        err = e.Unwrap()
        if err == nil {
            return nil
        }
    }
}

func main() {
    err1 := errors.New("error1")

    err2 := fmt.Errorf("2nd err: %w", err1)
    err3 := fmt.Errorf("3rd err: %w", err2)

    fmt.Println(err3) // 3rd err: 2nd err: error1

    fmt.Println(rootCause(err1)) // error1
    fmt.Println(rootCause(err2)) // error1
    fmt.Println(rootCause(err3)) // error1
}

第二种：通过errors.As函数将error chain中特定类型的error提取出来

error.As函数用于判断某个error是否是特定类型的error，如果是则将那个error提取出来，比如：

type MyError struct {
    err string
}

func (e *MyError) Error() string {
    return e.err
}

func main() {
    err1 := &MyError{"temp error"}
    err2 := fmt.Errorf("2nd err: %w", err1)
    err3 := fmt.Errorf("3rd err: %w", err2)

    fmt.Println(err3)

    var e *MyError
    ok := errors.As(err3, &e)
    if ok {
        fmt.Println(e)
        return
    }
}

在这个示例中，我们通过errors.As将错误链err3中的err1提取到e中，后续就可以使用err1这个特定错误的信息了。

3. 小结

错误链是Go中提供信息丰富的错误信息的一项重要技术。通过用额外的上下文包装错误，你可以提供关于错误的更具体的信息，并帮助开发人员更快地诊断出问题。

不过错误链在使用中有一些事项还是要注意的，比如：避免嵌套错误链。嵌套的错误链会使你的代码难以调试，也难以理解错误的根本原因。

结合错误链，通过给错误添加上下文，创建自定义错误类型，并在适当的抽象层次上处理错误，你可以写出简洁、可读和信息丰富的错误处理代码。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。