GopherCon | Tony Bai

标签 GopherCon 下的文章

Go 1.13中值得关注的几个变化

十月 27, 2019
0 条评论

2019年对于Go语言来说也是一个重要的年份，因为在2019年的11月10日，Go即将迎来其开源10周年的纪念日。在这个重要日子的前夕，在GopherCon 2019大会后，Go项目组在2019.9.4日发布了Go 1.13版本。

这是自2017年GopherCon大会上Russ Cox做“Toward Go 2″主题演讲以来Go项目发布的第四个版本（前三个分别是：go 1.10、go 1.11和go 1.12)。

Go2是这两年Go项目的核心主题。Go项目组也一直在摸索着向Go2演化的节奏和过程规范，并已经从Go 1.11版本起做出了实质性的动作：添加go module机制、错误处理优化、泛型讨论和多次草案的发布等。Russ Cox这段时间还在自己的博客上撰写了一系列有关Go proposal流程究竟该如何改进的探索性文章，这与当年vgo“放大招”前的节奏有些相似:)。

回归正题，我们来说Go 1.13这个版本。Go 1.13延续了对之前版本添加的Go2特性：Go module的优化；并且从该版本开始，Go项目组开启了Go2中呼声也很高的错误处理的优化。下面我们详细来看看Go 1.13中值得关注的几个变化。

1. 语言

Go 1.13中，Go语言规范有了一些小变化。

Go在设计伊始就和多数C-Family语言一样继承了C语言关于数字字面量(number literal)的语法形式，和1978年发布的K&R C一样，Go仅支持十进制、八进制、十六进制和十进制形式的浮点数的数字字面量形式，比如：

a := 53        //十进制

b := 0700      // 八进制，以"0"开头
c := 0xaabbcc  // 十六进制 以"0x"开头

c1 := 0Xddeeff // 十六进制 以"0X"开头

f1 := 10.24  // 十进制浮点数
f2 := 1.e+0  // 十进制浮点数
f3 := 31415.e-4 // 十进制浮点数

这些数字字面量语法应该说是够用的，但是和其他语言在进化过程中添加的其他数字字面量表达形式相比，又显得有些不足。于是Go设计者决定在Go 1.13版本中增加Go对数字字面量的表达能力，在这方面对Go语言做了如下补充：

增加二进制数字字面量，以0b或0B开头
在保留以”0″开头的八进制数字字面量形式的同时，增加以”0o”或”0O”开头的八进制数字字面量形式
增加十六进制形式的浮点数字面量，以0x或0X开头的、形式如0×123.86p+2的浮点数
为提升可读性，在数字字面量中增加数字分隔符”_”，分隔符可以用来分隔数字(起到分组提高可读性作用，比如每3个数字一组)，也可以用来分隔前缀与第一个数字。

a := 5_3_7
b := 0o700
b1 := 0O700
b2 := 0_700
b3 := 0o_700
c := 0b111
c1 := 0B111
c2 := 0b_111
f1 := 0x10.24p+3
f2 := 0x1.Fp+0
f3 := 0x31_415.p-4

注：截至目前，有些第三方工具依然无法识别数字字面量中的分隔符，会误报其为语法错误。

Go 1.13中关于语言规范方面的另一个变动点是取消了移位操作(>>的<<)的右操作数仅能是无符号数的限制，以前必须的强制到uint的转换现在不必要了：

var i int = 5

fmt.Println(2 << uint(i)) // before go 1.13
fmt.Println(2 << i)       // in go 1.13 and later version

不过值得注意的是：go 1.12版本在go.mod文件中增加了一个go version的指示字段，用于指示该module内源码所使用的 go版本。Go 1.13的发布文档强调了只有在go.mod中的go version指示字段为go 1.13(以及以后版本)时，上述的语言特性变更才会生效，否则就会报类似下面的错误：

// github.com/bigwhite/experiments/go1.13-examples/number_literal.go

$go run number_literal.go
# command-line-arguments
./number_literal.go:23:7: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:24:7: 0o/0O-style octal literals only supported as of -lang=go1.13
./number_literal.go:25:8: 0o/0O-style octal literals only supported as of -lang=go1.13
./number_literal.go:26:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:27:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:28:7: binary literals only supported as of -lang=go1.13
./number_literal.go:29:8: binary literals only supported as of -lang=go1.13
./number_literal.go:30:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:31:8: hexadecimal floating-point literals only supported as of -lang=go1.13
./number_literal.go:32:8: hexadecimal floating-point literals only supported as of -lang=go1.13
./number_literal.go:32:8: too many errors

// github.com/bigwhite/experiments/go1.13-examples/shift_with_signed_operand.go

$go run shift_with_signed_operand.go
# command-line-arguments
./shift_with_signed_operand.go:8:16: invalid operation: 2 << i (signed shift count type int, only supported as of -lang=go1.13)

当然，如果repo下没有go.mod或者单独在某个没有go.mod的目录下使用go 1.13编译器运行上面代码，则是无问题的。

2. Go module机制的继续优化以及行为变化

Go module自Go 1.11版本加入Go以来收到了Go社区的大量反馈，Go核心团队也针对这些反馈对Go module机制进行了持续地优化。在Go 1.13中，Go module的一些改变如下：

1) GO111MODULE=auto的行为变化

在Go 1.12版本中，GO111MODULE默认值为auto，在auto模式下，GOPATH/src下面的repo以及在GOPATH之外的repo依旧使用GOPATH mode，不使用go.mod来管理依赖；在Go 1.13中，module mode优先级提升，GO111MODULE的默认值依然为auto，但在这个auto下，无论是在GOPATH/src下还是GOPATH之外的repo中，只要目录下有go.mod，go编译器都会使用go module来管理依赖。

2) GOPROXY有默认初值并支持设置成多个代理的列表

之前版本中，GOPROXY这个环境环境变量默认值为空，go编译器都是直接与类似github.com这样的代码托管站点通信并获取相关依赖库的数据的；一些第三方GOPROXY服务发布后，迁移到go module的gopher们发现：大多数情况下通过proxy获取依赖包数据的速度要远高于直接从代码托管站点获取，因此GOPROXY总是会配置上一个值。Go核心团队也希望Go世界能有一个像nodejs那样的中心化的module仓库为大家提供服务，于是在Go 1.13中将https://proxy.golang.org作为GOPROXY环境变量的默认值之一，这也是Go官方提供的GOPROXY服务。

同时GOPROXY支持设置为多个proxy的列表(多个proxy之间采用逗号分隔)，Go编译器会按顺序尝试列表中的proxy以获取依赖包数据，但是当有proxy server服务不可达或者是返回的http状态码不是404也不是410时，go会终止数据获取。

Go 1.13中，GOPROXY的默认值为https://proxy.golang.org,direct。当官方代理返回404或410时，Go编译器会尝试直接连接依赖module的代码托管站点以获取数据。

由于国内无法访问Go官方的proxy，因此我一般会将我的工作环境下的GOPROXY设置为：

export GOPROXY=https://goproxy.cn,自己在国外主机使用athens搭建的代理,direct

3) GOSUMDB

我们知道go会在go module启用时在本地建立一个go.sum文件，用来存储依赖包特定版本的加密校验和。同时，Go维护下载的软件包的缓存，并在下载时计算并记录每个软件包的加密校验和。在正常操作中，go命令对照这些预先计算的校验和去检查某repo下的go.sum文件，而不是在每次命令调用时都重新计算它们。

在日常开发中，特定module版本的校验和永远不会改变。每次运行或构建时，go命令都会通过本地的go.sum去检查其本地缓存副本的校验和是否一致。如果校验和不匹配，则go命令将报告安全错误，并拒绝运行构建或运行。在这种情况下，重要的是找出正确的校验和，确定是go.sum错误还是下载的代码是错误的。如果go.sum中尚未包含已下载的module，并且该模块是公共module，则go命令将查询Go校验和数据库以获取正确的校验和数据存入go.sum。如果下载的代码与校验和不匹配，则go命令将报告不匹配并退出。

Go 1.13提供了GOSUMDB环境变量用于配置Go校验和数据库的服务地址（和公钥），其默认值为”sum.golang.org”，这也是Go官方提供的校验和数据库服务(大陆gopher可以使用sum.golang.google.cn)。

出于安全考虑，建议保持GOSUMDB开启。但如果因为某些因素，无法访问GOSUMDB（甚至是sum.golang.google.cn），可以通过下面命令将其关闭：

go env -w GOSUMDB=off

GOSUMDB关闭后，仅能使用本地的go.sum进行包的校验和校验了。

4）面向私有模块的GOPRIVATE

有了GOPROXY后，公共module的数据获取变得十分easy。但是如果依赖的是企业内部module或托管站点上的private库，通过GOPROXY（默认值）获取显然会得到一个失败的结果，除非你搭建了自己的公私均可的goproxy server并将其设置到GOPROXY中。

Go 1.13提供了GOPRIVATE变量，用于指示哪些仓库下的module是private，不需要通过GOPROXY下载，也不需要通过GOSUMDB去验证其校验和。不过要注意的是GONOPROXY和GONOSUMDB可以override GOPRIVATE中的设置，因此设置时要谨慎，比如下面的例子：

GOPRIVATE=pkg.tonyba.com/private
GONOPROXY=none

GONOSUMDB=none

GOPRIVATE指示pkg.tonybai.com/private下的包不经过代理下载，不经过SUMDB验证。但GONOPROXY和GONOSUMDB均为none，意味着所有module，不管是公共的还是私有的，都要经过proxy下载，经过sumdb验证。前面提到过了，GONOPROXY和GONOSUMDB会override GOPRIVATE的设置，因此在这样的配置下，所有依赖包都要经过proxy下载，也要经过sumdb验证。不过这个例子中的GOPRIVATE的值也不是一无是处，它可以给其他go tool提供私有module的指示信息。

3. Go错误处理优化迈出第一步

Go核心团队早在一年前就提出了关于go错误处理的多个proposal，其中涉及解决if err != nil 大量重复问题的，有解决错误包装(wrap)问题的，有解决error value比较问题的。在Go 1.13中，Go核心团队落实了后两个：

通过标准库增加了errors.Is和As函数来解决error value比较问题
增加errors.Unwrap来解决error unwrap问题。

并且Go通过在fmt.Errorf中新增的”%w”动词来协助Gopher快速创建一个包装错误，创建的error变量实现了下面接口：

interface { // 一个匿名接口

    Unwrap() error

}

关于Go 1.13中错误处理的改进，Go官方发表了一篇博客《Go 1.13中的错误处理》给出了十分详尽的说明，这里就不赘述了。

4. 性能

个人觉得Go 1.13中能带来性能提升的变动主要有三个：

第一个就是defer的性能提升。

defer语法让Gopher在进行资源(文件、锁)释放的过程变动优雅很多，也不易出错。但在性能敏感的应用中，defer带来的性能负担也是Gopher必须要权衡的问题。在Go 1.13中，Go核心团队对defer性能做了大幅优化，官方给出了在大多数情况下，defer性能提升30%的说法。

这里可以来验证一下：我们使用Go 1.13和Go 1.12.7两个版本运行同一个benchmark(macos 1.6G 8核 16G内存)：

// github.com/bigwhite/experiments/go1.13-examples/defer_benchmark_test.go

package defer_test

import "testing"

func sum(max int) int {
        total := 0
        for i := 0; i < max; i++ {
                total += i
        }

        return total
}

func foo() {
        defer func() {
                sum(10)
        }()

        sum(100)
}

func BenchmarkDefer(b *testing.B) {
        for i := 0; i < b.N; i++ {
                foo()
        }
}

go 1.13下的benchmark结果：

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8       17341530            67.3 ns/op
PASS
ok      command-line-arguments    1.245s

go 1.12.7下的benchmark结果：

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8       20000000            76.5 ns/op
PASS
ok      command-line-arguments    1.618s

我们看到性能的确有提升，但没有到30%这么大幅度，也许这仅仅是一个个例吧。
第二个是优化后的逃逸分析(escape analysis)让编译器在选择究竟将变量分配在stack上还是heap上的时候更加精确。在老版本里分配到heap上的变量，在Go 1.13中可能就会分配到stack上，从而减少内存分配的次数，一定程度上减轻gc的压力，达到性能提升的目的。

第三个是sync包中Mutex、RWMutex的方法的inline化带来的性能提升，官方说法是10%。我们同样来benchmark一下：

// github.com/bigwhite/experiments/go1.13-examples/mutex_benchmark_test.go

package mutex_test

import (
        "sync"
        "testing"
)

func sum(max int) int {
        total := 0
        for i := 0; i < max; i++ {
                total += i
        }

        return total
}

func foo() {
        var mu sync.Mutex
        mu.Lock()
        sum(10)
        mu.Unlock()
}

func BenchmarkMutex(b *testing.B) {
        for i := 0; i < b.N; i++ {
                foo()
        }
}

Go 1.13下的结果：

$go test -bench . mutex_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkMutex-8       43395768            26.4 ns/op
PASS
ok      command-line-arguments    1.182s

Go 1.12.7下的结果：

$go test -bench . mutex_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkMutex-8       50000000            28.4 ns/op
PASS
ok      command-line-arguments    1.457s

从结果看，提升在7%左右，约等于10%吧。

5. 其他变化

简单罗列一些我认为值得关注的小变化：

Go 1.13现在支持Android 10了；对MacOS的支持需要至少10.11版本；
godoc不再和go、gofmt放入go release版中，需要godoc的，需要单独从golang.org/x/tools/cmd/godoc中下载安装；
crypto/tls默认开启tls 1.3支持；
unicode包支持的unicode标准从10.0版本升级到Unicode 11.0版本

6. 小结

Go 1.13版本的发布标志着Go向着Go2的目标又迈出了坚实的一步，Go的演化节奏也是恰到好处：

go module已经落地成型，逐渐打磨到成熟；
错误处理：迈出阶段性的一步，后续持续改进
Go generics: 是Go2最大的”挑战”。我们看到在GopherCon 2019大会上，Ian Lance Taylor带来的有关Go generics的proposal的改进正在被越来越多Gopher所认可。

不过按照go team的行事风格，任何一个proposal都会经历”实验，简化和发布”的步骤，Go generics还有很长的路要走，让我们共同期待！

本文中涉及的样例源码可以在这里获取到。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商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
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：
img{512x368}

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

Go 1.13中的错误处理

十月 18, 2019
6 条评论

介绍

在过去的十年中， Go的errors are values的理念在编码实践中运行得也很良好。尽管标准库对错误处理的的支持很少（只有errors.New和fmt.Errorf函数可以用来构造仅包含字符串消息的错误），但是内置的error接口使Go程序员可以添加所需的任何信息。它所需要的只是一个实现Error方法的类型：

type QueryError struct {
    Query string
    Err   error
}

func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }

像这样的错误类型无处不在，它们存储的信息变化很大，从时间戳到文件名再到服务器地址。通常，该信息包括另一个较低级别的错误以提供其他上下文信息。

在Go代码中，使用一个包含了另一个错误的错误类型的模式十分普遍，以至于经过广泛讨论后，Go 1.13为其添加了明确的支持。这篇文章描述了标准库提供的支持：errors包中的三个新功能，以及fmt.Errorf中添加的新格式化动词。

在详细描述这些变化之前，让我们先回顾一下在Go语言的早期版本中如何检查和构造错误。

Go 1.13版本之前的错误处理

检查错误

错误是值(errors are values)。程序通过几种方式基于这些值来做出决策。最常见的是通过与nil的比较来确定操作是否失败。

if err != nil {
    // 出错了!
}

有时我们将错误与已知的前哨值(sentinel value)进行比较来查看是否发生了特定错误。比如：

var ErrNotFound = errors.New("not found")

if err == ErrNotFound {
    // something wasn't found
}

错误值可以是满足语言定义的error 接口的任何类型。程序可以使用类型断言(type assertion)或类型开关(type switch)来判断错误值是否可被视为特定的错误类型。

type NotFoundError struct {
    Name string
}

func (e *NotFoundError) Error() string { return e.Name + ": not found" }

if e, ok := err.(*NotFoundError); ok {
    // e.Name wasn't found
}

添加信息

函数通常在将错误向上传递给调用堆栈时添加额外错误信息，例如对错误发生时所发生情况的简短描述。一种简单的方法是构造一个新错误，并在其中包括上一个错误：

if err != nil {
    return fmt.Errorf("decompress %v: %v", name, err)
}

使用fmt.Errorf创建的新错误将丢弃原始错误中的所有内容（文本除外）。就像我们在前面所看到的QueryError那样，有时我们可能想要定义一个包含基础错误的新错误类型，并将其保存下来以供代码检查。我们再次来看一下QueryError：

type QueryError struct {
    Query string
    Err   error
}

程序可以查看一个*QueryError值的内部以根据潜在的错误进行决策。有时您会看到称为“展开”错误的信息。

if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
    // query failed because of a permission problem
}

标准库中的os.PathError类型就是另外一个在错误中包含另一个错误的示例。

Go 1.13版本的错误处理

Unwrap方法

Go 1.13在errors和fmt标准库包中引入了新功能以简化处理包含其他错误的错误。其中最重要的不是改变，而是一个约定：包含另一个错误的错误可以实现Unwrap方法来返回所包含的底层错误。如果e1.Unwrap()返回了e2，那么我们说e1包装了e2，您可以Unwrap e1来得到e2。

遵循此约定，我们可以为上面的QueryError类型提供一个Unwrap方法来返回其包含的错误：

func (e *QueryError) Unwrap() error { return e.Err }

Unwrap错误的结果本身(底层错误)可能也具有Unwrap方法。我们将这种通过重复unwrap而得到的错误序列为错误链。

使用Is和As检查错误

Go 1.13的errors包中包括了两个用于检查错误的新函数：Is和As。

errors.Is函数将错误与值进行比较。

// Similar to:
//   if err == ErrNotFound { … }
if errors.Is(err, ErrNotFound) {
    // something wasn't found
}

As函数用于测试错误是否为特定类型。

// Similar to:
//   if e, ok := err.(*QueryError); ok { … }
var e *QueryError
if errors.As(err, &e) {
    // err is a *QueryError, and e is set to the error's value
}

在最简单的情况下，errors.Is函数的行为类似于上面对哨兵错误(sentinel error))的比较，而errors.As函数的行为类似于类型断言(type assertion)。但是，在处理包装错误(包含其他错误的错误）时，这些函数会考虑错误链中的所有错误。让我们再次看一下通过展开QueryError以检查潜在错误：

if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
    // query failed because of a permission problem
}

使用errors.Is函数，我们可以这样写：

if errors.Is(err, ErrPermission) {
    // err, or some error that it wraps, is a permission problem
}

errors包还包括一个新Unwrap函数，该函数返回调用错误Unwrap方法的结果，或者当错误没有Unwrap方法时返回nil。通常我们最好使用errors.Is或errors.As，因为这些函数将在单个调用中检查整个错误链。

用%w包装错误

如前面所述，我们通常使用fmt.Errorf函数向错误添加其他信息。

if err != nil {
    return fmt.Errorf("decompress %v: %v", name, err)
}

在Go 1.13中，fmt.Errorf函数支持新的%w动词。当存在该动词时，所返回的错误fmt.Errorf将具有Unwrap方法，该方法返回参数%w对应的错误。%w对应的参数必须是错误(类型)。在所有其他方面，%w与%v等同。

if err != nil {
    // Return an error which unwraps to err.
    return fmt.Errorf("decompress %v: %w", name, err)
}

使用%w创建的包装错误可用于errors.Is和errors.As：

err := fmt.Errorf("access denied: %w”, ErrPermission)
...
if errors.Is(err, ErrPermission) ...

是否包装

在使用fmt.Errorf或通过实现自定义类型将其他上下文添加到错误时，您需要确定新错误是否应该包装原始错误。这个问题没有统一答案。它取决于创建新错误的上下文。包装错误将会被公开给调用者。如果要避免暴露实现细节，那么请不要包装错误。

举一个例子，假设一个Parse函数从io.Reader读取复杂的数据结构。如果发生错误，我们希望报告发生错误的行号和列号。如果从io.Reader读取时发生错误，我们将包装该错误以供检查底层问题。由于调用者为函数提供了io.Reader，因此有理由公开它产生的错误。

相反，一个对数据库进行多次调用的函数可能不应该将其中调用之一的结果解开的错误返回。如果该函数使用的数据库是实现细节，那么暴露这些错误就是对抽象的违反。例如，如果你的程序包pkg中的函数LookupUser使用了Go的database/sql程序包，则可能会遇到sql.ErrNoRows错误。如果使用fmt.Errorf(“accessing DB: %v”, err)来返回该错误，则调用者无法检视到内部的sql.ErrNoRows。但是，如果函数使用fmt.Errorf(“accessing DB: %w”, err)返回错误，则调用者可以编写下面代码：

err := pkg.LookupUser(...)
if errors.Is(err, sql.ErrNoRows) …

此时，如果您不希望对客户端源码产生影响，该函数也必须始终返回sql.ErrNoRows，即使您切换到其他数据库程序包。换句话说，包装错误会使该错误成为您API的一部分。如果您不想将来将错误作为API的一部分来支持，则不应包装该错误。

重要的是要记住，无论是否包装错误，错误文本都将相同。那些试图理解错误的人将得到相同的信息，无论采用哪种方式; 是否要包装错误的选择是关于是否要给程序提供更多信息，以便他们可以做出更明智的决策，还是保留该信息以保留抽象层。

使用Is和As方法自定义错误测试

errors.Is函数检查错误链中的每个错误是否与目标值匹配。默认情况下，如果两者相等，则错误与目标匹配。另外，链中的错误可能会通过实现Is方法来声明它与目标匹配。

例如，下面的错误类型定义是受Upspin error包的启发，它将错误与模板进行了比较，并且仅考虑模板中非零的字段：

type Error struct {
    Path string
    User string
}

func (e *Error) Is(target error) bool {
    t, ok := target.(*Error)
    if !ok {
        return false
    }
    return (e.Path == t.Path || t.Path == "") &&
           (e.User == t.User || t.User == "")
}

if errors.Is(err, &Error{User: "someuser"}) {
    // err's User field is "someuser".
}

同样，errors.As函数将使用链中某个错误的As方法，如果该错误实现了As方法。

错误和包API

返回错误的程序包（大多数都会返回错误）应描述程序员可能依赖的那些错误的属性。一个经过精心设计的程序包也将避免返回带有不应依赖的属性的错误。

最简单的规约是用于说明操作成功或失败的属性，分别返回nil或non-nil错误值。在许多情况下，不需要进一步的信息了。

如果我们希望函数返回可识别的错误条件，例如“item not found”，则可能会返回包装哨兵的错误。

var ErrNotFound = errors.New("not found")

// FetchItem returns the named item.
//
// If no item with the name exists, FetchItem returns an error
// wrapping ErrNotFound.
func FetchItem(name string) (*Item, error) {
    if itemNotFound(name) {
        return nil, fmt.Errorf("%q: %w", name, ErrNotFound)
    }
    // ...
}

还有其他现有的提供错误的模式，可以由调用方进行语义检查，例如直接返回哨兵值，特定类型或可以使用谓词函数检查的值。

在所有情况下，都应注意不要向用户公开内部细节。正如我们在上面的“是否要包装”中提到的那样，当您从另一个包中返回错误时，应该将错误转换为不暴露基本错误的形式，除非您愿意将来再返回该特定错误。

f, err := os.Open(filename)
if err != nil {
    // The *os.PathError returned by os.Open is an internal detail.
    // To avoid exposing it to the caller, repackage it as a new
    // error with the same text. We use the %v formatting verb, since
    // %w would permit the caller to unwrap the original *os.PathError.
    return fmt.Errorf("%v", err)
}

如果将函数定义为返回包装某些标记或类型的错误，请不要直接返回基础错误。

var ErrPermission = errors.New("permission denied")

// DoSomething returns an error wrapping ErrPermission if the user
// does not have permission to do something.
func DoSomething() {
    if !userHasPermission() {
        // If we return ErrPermission directly, callers might come
        // to depend on the exact error value, writing code like this:
        //
        //     if err := pkg.DoSomething(); err == pkg.ErrPermission { … }
        //
        // This will cause problems if we want to add additional
        // context to the error in the future. To avoid this, we
        // return an error wrapping the sentinel so that users must
        // always unwrap it:
        //
        //     if err := pkg.DoSomething(); errors.Is(err, pkg.ErrPermission) { ... }
        return fmt.Errorf("%w", ErrPermission)
    }
    // ...
}