100 个 Go 常见错误及如何避免它们

由于Go语言在设计包和模块时提供了很大的自由度，最佳实践并没有像应有的那样普及。本节首先讨论结构化项目的常见方法，然后探讨一些最佳实践，展示如何改进我们组织项目的方式。

在设计 API 时，可能会产生一个问题：如何处理可选配置？高效解决这个问题可以提高我们 API 的便利性。本节通过一个具体示例，涵盖了处理可选配置的不同方法。

当创建一个结构体时，Go 提供了嵌入类型的选项。但如果我们不理解类型嵌入的所有含义，这有时会导致意想不到的行为。在本节中，我们将探讨如何嵌入类型，这些操作带来了什么，以及可能出现的问题。

Go 1.18 引入了泛型到语言中。简而言之，这允许我们编写具有可以稍后指定并在需要时实例化的类型的代码。然而，何时使用泛型以及何时不使用可能会让人感到困惑。

随着 Go 1.18 的发布，预声明的类型 any 成为了空接口的别名；所有的 interface{} 都可以被 any 替换。

在设计函数签名时，我们可能需要返回接口或具体实现。让我们理解为什么在许多情况下，返回接口在 Go 中被认为是一种不良实践。

在前一节中，我们讨论了何时接口被认为有价值。但 Go 开发人员经常误解一个问题：接口应该放置在哪里？

接口是 Go 语言设计和构建代码时的基石之一。然而，就像许多工具或概念一样，滥用它们通常不是一个好主意。接口污染是指用不必要的抽象概念压倒我们的代码，使代码更难理解。

通过在未导出的对象字段上提供导出的方法，getter 和 setter 是实现封装的手段。Go 语言中并没有像一些其他语言那样自动支持 getter 和 setter

有时我们在 Go 应用程序中滥用 init 函数。潜在的后果是错误管理不善或代码流程更难理解。让我们回顾一下 init 函数是什么。然后，我们将看看何时推荐或不推荐使用它。

根据命名、一致性、格式化等多重标准，代码被认为具有可读性。可读性高的代码需要较少的认知努力来维持心理模型；因此，它更容易阅读和维护。

按照Go语言的惯用法组织我们的代码。 高效地处理抽象概念：接口和泛型。 关于如何构建项目的最优实践。

本章内容包括: Go语言的高效、可扩展和高产出的原因 探讨Go语言易学难精的原因 描述开发者常见的错误类型 做错误是每个人生活的一部分。正如阿尔伯特·爱因斯坦曾说过的: “一个从未犯过错误的人,从未尝