我在 Go 中犯的 5 个错误

人皆犯错，宽恕是德 — Alexander Pope

这些都是我在写 Go 中犯的错误。尽管这些可能不会导致任何类型的错误，但它们可能会潜在地影响软件。

内循环

有几种方法可以造成循环内部的混乱，你需要注意。

1.1 使用引用循环迭代变量

由于效率的原因，循环迭代变量是单个变量，在每次循环迭代中采用不同的值。这可能会导致不知情的行为。

结果将是：

正如你所看到的，out 切片中的所有元素都是 3。实际上，实际上很容易解释为什么会发生这种情况：在每次迭代中，我们都会将 v 的地址附加到 out 切片中。如前所述，v 是在每次迭代中接受新值的单个变量。因此，正如您在输出的第二行中看到的，地址是相同的，并且所有地址都指向相同的值。

简单的解决方法是将循环迭代器变量复制到新变量中：

新的输出：

同样的问题可以找到正在 Goroutine 中使用的循环迭代变量。

结果将是：

它可以使用上面提到的相同的解决方案来修复。注意，如果不使用 Goroutine 运行该函数，代码将按照预期运行。

1.2 在循环中调用 WaitGroup.Wait

使用 WaitGroup 类型的共享变量会犯此错误，如下面的代码所示，当第 5 行的 Done()被调用 len(tasks) 次数时，第 7 行的 Wait() 只能被解除阻塞，因为它被用作参数在第 2 行调用 Add()。但是，Wait() 在循环中被调用，因此在下一个迭代中，它会阻止在第 4 行创建 Goroutine。简单的解决方案是将 Wait() 的调用移出循环。

1.3 在循环中使用 defer

defer 直到函数返回才执行。除非你确定你在做什么，否则你不应该在循环中使用 defer。

在上面的例子中，如果你使用第 8 行而不是第 10 行，下一次迭代就不能持有互斥锁，因为锁已经在使用中，并且循环永远阻塞。

如果你真的需要使用 defer 内循环，你可能想委托另一个函数来做这项工作。

但是，有时使用 defer 在循环可能会变得很方便。所以你真的需要知道你在做什么。

Go 不能容忍愚蠢者

发送到一个无保证的 channel

您可以将值从一个 Goroutine 发送到 channels，并将这些值接收到另一个 Goroutine。默认情况下，发送和接收，直到另一方准备好。这允许 Goroutines 在没有显式锁或条件变量的情况下进行同步。

让我们检查一下上面的代码。doReq 函数在第 4 行创建一个子 Goroutine 来处理请求，这在Go服务程序中是一种常见的做法。子 Goroutine 执行 do 函数并通过第 6 行通道 ch 将结果发送回父节点。子进程会在第 6 行阻塞，直到父进程在第 9 行接收到 ch 的结果。同时，父进程将阻塞 select，直到子进程将结果发送给 ch（第9行）或发生超时（第11行）。如果超时发生在更早的时候，父函数将从第 12 行 doReq 方法返回，并且没有人可以再接收 ch 的结果，这将导致子函数永远被阻塞。解决方案是将 ch 从无缓冲通道更改为缓冲通道，这样即使父及退出，子 Goroutine 也始终可以发送结果。另一个修复方法是在第 6 行使用默认为空的 select 语句，这样如果没有 Goroutine 接收 ch，就会发生默认情况。尽管这种解决方案可能并不总是有效。

不使用接口

接口可以使代码更加灵活。这是在代码中引入多态的一种方法。接口允许您请求一组行为，而不是特定类型。不使用接口可能不会导致任何错误，但它会导致代码不简单、不灵活和不具有可扩展性。

在众多接口中，io.Reader 和 io.Writer 可能是最受欢迎的。

这些接口可以非常强大。假设您要将对象写入文件中，因此您定义了一个 Save 方法：

如果您第二天需要写入 http.ResponseWriter 该怎么办？您不想定义新方法。是吧？所以使用 io.Writer。

还有一个重要的注意事项，你应该知道，总是要求你要使用的行为。在上面的例子中，请求一个io.ReadWriteCloser 也可以工作得很好，但当你要使用的唯一方法是 Write时，这不是一个最佳实践。接口越大，抽象就越弱。

所以大多数时候你最好专注于行为而不是具体的类型。

不好的顺序结构

这个错误也不会导致任何错误，但是它会导致更多的内存使用。

似乎两种类型的大小都相同，为 21 个字节，但结果显示出完全不同。使用 GOARCH=amd64 编译代码，BadOrderedPerson 类型分配 32 字节，而 OrderedPerson类型分配 24 字节。为什么？原因是数据结构对齐。在 64 位体系结构中，内存分配 8 字节的连续数据包。需要添加的填充可以通过以下方式计算：