深度阅读之《100 Go Mistakes and How to Avoid Them》

梦醒人间

发布于 2023-02-28 15:41:15

1K0

发布于 2023-02-28 15:41:15

文章被收录于专栏：码农桃花源

继《Mastering Go》和《Concurrency in Go》[1]之后，这是我精读的第 3 本 Go 主题的英文书了。全书 390+ 页，从开始读到全部读完，快 2 个月了，😓。

前不久曹大连接发了几个关于《100 mistakes》的视频，多猜他大都是看看标题，看看代码，就知道要说什么了，并且很快就跳过去，速度飞快。我开始设想的是除了读懂内容，还想练习一下英语阅读，慢就慢吧。不过，我过后也确实加快了速度，毕竟人家半小时的进度我要两周，稍微有点离谱。

简单谈一下这本书：全书“凑”了 100 个关于 Go 的错误。有些是非常经典且常见的错误，例如在 for 循环中保存迭代变量的指针、并发 append slice 等等，书中做了非常详细的讲述。另外有一些错误则见得不多，有凑数的嫌疑，例如很多错误是不知道 xxx、不懂 xxx……读来稍微有点别扭。还有一些瑕疵的地方是第 8 章关于 M 的描述是错误的……

关于书名，作者还找了几个为什么要从 mistakes 中学习的理由：我们印象最深的知识点一定是在犯错的场景下学到的。

Tell me and I forget. Teach me and I remember. Involve me and I learn.

我们最近正在组织这本书的翻译，估计明年 5 月左右能上市，不过还是建议大家读读英文版。

以下是我在读书的过程中所做的一些笔记，记下我认为今后可能会遇到的坑。

Go 很简单，但不容易掌握

Go is simple but not easy.

简单意味着易懂，Go 语法基本上花 2 小时就能全部看完。但是要想掌握它、写好它却不容易。比如，goroutine 和 channel 该简单了吧，但是使用 channel 出错的 case 数不胜数。

之前有篇讲 Concurrency bugs 的论文《Understanding Real-World Concurrency Bugs in Go》[2]说：尽管人们普遍认为通过 channel 来传递消息更少出错误，但是论文里研究的 bug 表明，正好相反，用 mutex 才更少出错。

The bigger the interface, the weaker the abstraction

Rob Pike说：The bigger the interface, the weaker the abstraction。当一个接口的方法越多，它的抽象能力越弱。像接口 Reader/Writer 为何很强大，因为它们就只有一个方法。

他还说：Don’t design with interfaces, discover them. 意思就是只有在实现过程中发现需要 interface 时才需要定义。是自下而上的过程，而非相反。

net 包和 net/http 包并没有层级关系

可以认为是两个不同的包，它们仅仅是文件位置有层级关系而已。

包名要反映这个包能提供什么能力，而不是它包含了哪些内容。

函数名反映它做了什么，而不是怎么做。虽然命名一直是编程界的难题，但不断尝试好的命名也是必要的。日常的 util, common, base 这些包名其实并不好。任何对外暴露的内容：包、函数、方法、变量都应该给出说明。

nil slice 的几个特点

不分配内存。对于一个函数的返回值而言，返回 nil slice 比 emtpy slice 要更好。

在 marshal 时，nil slice 是 null，而 empty slice 是 []。因此在使用相关库函数时，要特别注意这两者的区别。

nil slice 和 empty slice 不 equal。

以下代码中前 2 个是 nil slice，后两个不是。

copy 函数拷贝的元素数量是 min(len(dst), len(min))
初始化 map 时，指定一个长度

它能给 runtime 以提示，这样后续可以减少重新分配元素的开销。并且要注意：这个长度并不是说 map 只能放这么多元素，这里面有一个公式会计算。

map 的 buckets 数只会增，不会降。所以当在流量冲击后，map 的 buckets 数扩容到了一个新高度，之后即使把元素都删除了也无济于事。内存占用还是在，因为基础的 buckets 占用的内存不会少。

关于这一点，之前专门写过一篇Go map 竟然也会发生内存泄漏？[3]去讲，私以为比书里讲得更详细。

不要边遍历 map 边写入 key

在遍历 map 的过程中，新写入的 key 可能被遍历出来，也可能不被遍历出来，可能会与预期的行为不符，因此不要边遍历边写入。

下面这个例子输出的结果不确定：

func main() {
 m := map[int]bool{
  0: true,
  1: false,
  2: true,
 }

 for k, v := range m {
  if v {
   m[10+k] = true
  }
 }
 
 fmt.Println(m)
}

break 可以作用于 for, select, switch

break 只能跳出一重循环，因此要注意，break 是否跳到了你预想的地方。可以用 break with label 来解决。毕竟标准库里也这样用了：

for 循环加指针，老司机也会掉的坑

在 for range 循环里保存迭代变量的指针是一个非常容易犯的错误，Go 老手也会犯。原因是迭代变量至始至终都是同一个值，对它取地址得到的值也是相同的：

rune 代表一个“字”，等于 Unicode 中的 code point。

因为在 UTF-8 中，一个字被编码成 1-4 个 bytes，因此 rune 被定义成了 int32。例如，汉字的编码是：0xE6, 0xB1, 0x89。

func main() {
 // len 返回的是 Byte 数量
    // 3
 fmt.Println(len("汉"))

 s := string([]byte{0xE6, 0xB1, 0x89})
    // 汉
 println(s)
 
 // 查看 rune 数量
    // 1
 fmt.Println(utf8.RuneCountInString(s))
}

TrimLeft, TrimRight 的坑

TrimLeft, TrimRight 会从 source string 里移除给定字符串里的字符（只要存在就移除），直到碰到一个不存在于给定字符串里的字符时结束；TrimPrefix, TrimSuffix 则要完全匹配，才会移除。Trim 等同于 TrimLeft+TrimRight。13. 因为 Go 里面的 string 是不可变的，因此使用 += 来连接字符串时，其实是重新分配了一个新字符串。

使用 strings.Builder 时，可以用 Grow 方法来预分配内存，我自己之前一直忽略了预分配。因为它的底层是一个 slice，所以预分配 slice 是有必要的。

string 和 []byte 之间的转换会有内存分配发生

所以除了一些 hack 方式的转换外，另外一个可替代的做法是在一些情况下直接用 bytes 包的方法，从而避免转换成 string：strings 包有的方法，byte 包也基本都有，比如 Split, Contains 等等。

转 string 的做法在标准库中是这么做的，见 strings.Clone 方法：

当我们需要取出一个 slice 里的小部分元素时，为了防止取字符串子串时内存泄漏，下面这种做法可能会在编译器中“误伤”，但这种转换是必要的，它发生了内存分配，因此和原字符串脱离了关系。另一种可选的方法是调用 strings.Clone 方法：

关于具名返回值。

什么时候需要给返回值命名呢？没有一个必须遵循的原则。取名字有两个场景：增加可读性(例如返回经度、纬度两个字段，如果不命名，鬼知道哪个前哪个后)；利用它会自动初始化为零值，能让代码更短一些，当然，代码本身也得比较短。

另外，关于 return 时加不加名字。函数代码比较长时，还是带上比较好，增加可读性，不然看代码的人一直要记住返回值是什么。

在同一个函数里，统一返回值的风格，不要一会儿返回带名字的参数，一会儿又直接 return。

即使给返回值命名了，也不意味着一定要直接 return，还是可以带名字 return。

方法的语法糖

Having a nil receiver is allowed, and an interface converted from a nil pointer isn’t a nil interface.

这句话非常绕，也很容易犯错。前半句，当 receiver 是 nil 的时候，依然可以调用方法，因为实际上方法是一个语法糖。

当返回参数是一个自定义的 interface 时，尤其是自定义的 Error interface 时，直接返回 nil，而不要返回一个 nil 的 pointer，因为它不是 nil，且这往往造成后续的判空逻辑出错，这同样是一个很常见的错误。

defer 一个 func 时，参数马上就会求值

然后这个函数调用就会被压栈，等函数 return 时再来执行，参数值用的是之前已经算好了的，如果参数不是指针，那程序的行为可能就不是预期的那样了。

这种情况还可以用闭包解决，闭包内里的参数就是在真正执行的时候才去求值的。下面这个闭包同时还包含一个参数：

panic 和 error

一般 error 都是作为返回值的最后一个。有些错误处理方案不处理 error，企图直接在 defer 里看有没有 panic，这其实是模拟的 Java/C++ 等语言里对异常的处理方法。Go 一般不这么做。

panic 发生时，程序执行流程会一直“出栈”直到当前进程退出或者被 recover 掉。

为什么 recover 一定要写在 defer 里才生效呢？因为只有在 defer 里的语句才能在发生 panic 后也能执行。还有个问题是为什么 recover 非得要包一层才能有效呢？这是 Go 明确规定的。可能有两方面原因：recover 有一个返回值，它表示 panic 的原因，所以得有地方把它“打印”出来；Go 在实现上需要用到栈的层级关系。具体的就需要深入研究下源码。stackoverflow[4]

当我们要返回一个确定的、预期内的错误时，应该返回一个预先定义的 error value，也被称为 sentinel error；当返回非预期的错误时，返回特定的 error type。前者用 errors.Is 判断，后者用 errors.As 判断。

几种不同错误处理方式。用 %w 是 wrap，用 %v 是转换。前者可以看到 source error，可以用 As/Is 比较，后者看不到。

关于 context 取消

A Context carries a deadline, a cancellation signal, and other values across API boundaries.

context 被取消时，可以通过 Done() 方法返回的 channel 感知到。当 cancel 方法被调用、deadline 过期时，context 被取消。Done() 返回的 channel 被关闭。通过 Err() 方法可以感知到 context 为什么会被取消。

另外，context 是并发安全的。

channel 有一个魔法是：关闭 channel，可以让所有的 receiver 感知到。而向 channel 发送数据，只能有一个 receiver 能收到。

context 的 key 类型如何设置

当设置 key/value 时，key 和 value 可以是任意类型；对于 key 而言，通常不是直接用字符串，而是用一个非导出的类型，这样不会发生冲突。

如何通过自定义的方式来继承一个 context 里的 value，而不继承它的信号。

type detach struct {
 ctx context.Context
}

func (d detach) Deadline() (time.Time, bool) {
 return time.Time{}, false
}

func (d detach) Done() <-chan struct{} {
 return nil
}

func (d detach) Err() error {
 return nil
}

func (d detach) Value(key any) any {
 return d.ctx.Value(key)
}

闭包是一个使用函数体外变量的匿名函数。它和 goroutine, for 循环结合使用时，经常会出现意料之外的问题，老司机也经常在这里翻车。

package main

import "fmt"

func listing1() {
 s := []int{1, 2, 3}

 for _, i := range s {
  go func() {
   fmt.Print(i)
  }()
 }
}

func listing2() {
 s := []int{1, 2, 3}

 for _, i := range s {
  val := i
  go func() {
   fmt.Print(val)
  }()
 }
}

func listing3() {
 s := []int{1, 2, 3}

 for _, i := range s {
  go func(val int) {
   fmt.Print(val)
  }(i)
 }
}

listing1 里因为是闭包，所以 Print 是在打印的时候才会真正求 i 的值，而 goroutine 什么时候执行是不确定的。因此打印时，可能是 2，也可能是 3，且 goroutine 打印的值还可能重复。例如打印出 233 时图解如下：

listing2 用本地变量，可以解决。

listing3 不用闭包，同样能解决问题。

用 map[K]struct{} 这种形式来表示 set 不光是节省内存，还能明确表达出这是一个 set 的含义；如果把 struct{} 换成 bool 意义就没这么明确了。
context 相关的并发问题

书里给了一个etcd里的例子，用 context 里的 k-v 做 key，然后遇到了并发(一个 goroutine 读所有的 value，另一个 goroutine 会更新某个可变的 value，例如 key 是一个指针，指向 struct)的问题，所以就自定义了一个 blankCtx 来拦截 String() 方法，消除并发问题。

这种问题应该还挺多的。context 里的 value 如果有可变类型，那么就会很容易导致 data race 的问题。

The fix https://github.com/etcd-io/etcd/pull/7816 was to not rely on fmt.Sprintf to format the map’s key to prevent traversing and reading the chain of wrapped values in the context. Instead, the solution was to implement a custom streamKeyFromCtx function to extract the key from a specific context value that wasn’t mutable.