学习Golang时遇到的似懂非懂的概念
背景🐋
这是我学习golang的第三天，大致已经掌握了golang的语法，但是着手开发的时候，却遇到了许多问题，例如golang导包机制、golang的项目管理规范、go mod生成project怎么管理依赖的等等。其实这些概念之前也了解过，但是也只是如蜻蜓点水般的了解。正好，现在遇到了这些问题，那便认真总结一番。
问题总结
一个优秀的Go项目的布局是怎样的？😎
这个我在网上搜了很多的资料，不管是博客还是视频，他们大部分教的是在Go ENV路径下创建你的project，然后cd到你的project，接着在该项目文件夹下创建bin、src 和pkg目录。目录布局大致如下：
.
├── bin
├── pkg
├── src
│ ├── github.com
│ │ ├── user
│ │ │ └── project1
│ │ └── user
│ │ └── project2
│ ├── main.go
│ └── other.go
├── vendor
├── Makefile
└── README.md
bin目录放置编译生成的可执行文件。pkg目录放置编译生成的包文件。src目录是源码目录，它包含了项目的所有Go源代码，外部依赖库的源代码也可以放在该目录下。vendor目录存储了第三方依赖库的代码，类似于其他语言中的node_modules目录或pip的virtualenv机制。Makefile包含了项目的构建与管理规则，如编译、测试、部署等。README.md文件包含了项目的说明文档和使用说明。
这种目录布局其实还挺清晰的，但是自从go引入go modules做依赖管理，项目布局结构会变得更精简，更灵活。具体目录布局如下所示：
.
├── cmd
│ └── main.go
├── internal
├── pkg
├── vendor
├── go.mod
└── README.md
cmd目录是程序的入口代码，即main函数的实现。internal目录用于存放应用程序的私有代码，不能被其他项目引用。pkg目录用于存放应用程序的公共库代码，可以被其他项目引用。vendor目录用于存放依赖库的代码，类似于其他语言中的node_modules目录或pip的virtualenv机制。go.mod是 Go modules 的配置文件，用于管理依赖关系和版本控制。README.md文件包含了项目的说明文档和使用说明。
当然根据业务要求，我们还可以添加docs目录存放项目文档，添加test目录存放单元测试代码。
Tonybai大佬的图画的相当不错，我这边引用一下，大家看完图就知道一个Go语言的经典布局该是什么样的了。
ps：图有点糊，将就一下......
项目结构目录重点突出一个清晰明了，我们需要清楚每个目录代表的含义是什么，每个目录下的文件有哪些，目录文件的调用关系，目录文件的隐蔽性等等。
为什么一定是go mod？🤔
我提出这个问题并不是吹毛求疵，而是真心想了解在没go module管理时，大家不也写的好好的么，为什么go module出来后，大家会立马抛弃以前的做法。这 go module到底带来了什么好处，如此吸引人。
我还是从项目布局上理解，在没有go module管理时，大家的项目布局应该长这样：
.
├── bin
├── pkg
├── src
│ ├── github.com
│ │ ├── user
│ │ │ └── project1
│ │ └── user
│ │ └── project2
│ ├── main.go
│ └── other.go
├── vendor
├── Makefile
└── README.md
首先在 Go 1.11 版本之前，如果要在 $GOPATH 中运行一个项目，该项目必须存放在 $GOPATH/src 目录下。布局里就包含了project1和project2两个项目文件目录。这会导致你的src目录越来越肿大。
其次是手动管理依赖问题。在Go 1.11版本之前，Go 语言没有官方的依赖管理工具，因此在项目中引入外部依赖库的时候，通常需要手动将依赖库的代码拷贝到 $GOPATH/src 目录下。这个光不是手动下载的事，你还要考虑到手动更新，依赖之间的冲突问题，部署的问题等等。在倡导DEVOPS的时代，哪一个都是让人分心头痛的事😣。
然而，go module解决了上述问题（怪不得大家会极力拥抱这门新技术）。这里举个例子说明两者的差别，让思路更清晰。
假设有两个项目 A 和项目 B，都依赖于 Go 语言的一个第三方库 github.com/gin-gonic/gin。其中，项目 A 使用传统的依赖管理方式，项目 B 使用 Go modules 来管理依赖。
一、使用传统的依赖管理方式的项目 A：
项目 A 的目录结构如下：
.
├── main.go
└── vendor
└── github.com
└── gin-gonic
└── gin
├── LICENSE
├── README.md
├── bindings
├── contributing.md
├── favicon.ico
├── gin.go
├── go.mod
├── go.sum
├── handlers
├── logger.go
├── middleware.go
├── render
├── router.go
└── vendor
main.go 文件中引入了 github.com/gin-gonic/gin：
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
r := gin.Default()
// ...
}
在项目 A 中，依赖库 github.com/gin-gonic/gin 的代码被存放在 vendor 目录中，无法和其他项目共享使用。需要说明地是，使用 vendor 目录来管理依赖库是 Go 语言在 Go 1.5 版本时引入的方式。在使用 vendor 目录管理依赖库的时候，你需要将依赖库的代码复制到项目目录下的 vendor 目录下，然后在代码中引用这些依赖库。如果这个依赖库的版本发生升级，需要手动更新并重新拷贝代码到 vendor 目录，容易出现版本冲突或遗漏问题。
二、使用 Go modules 的项目 B：
项目 B 的目录结构如下：
.
├── go.mod
├── main.go
└── vendor
main.go 文件中同样引入了 github.com/gin-gonic/gin：
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
r := gin.Default()
// ...
}
在项目 B 中，使用 go mod 命令来管理依赖库和版本，无需手动拷贝依赖库代码。执行以下命令会自动下载依赖库代码至 $GOPATH/pkg/mod 目录下：
go mod init example.com/B
go mod tidy
安装完依赖库后，可以把 $GOPATH/pkg/mod 目录下的 github.com/gin-gonic/gin 目录拷贝到其他项目中使用，从而实现依赖共享。如果需要升级或切换依赖库的版本，只需要修改 go.mod 文件中的版本号即可，不会影响到其他项目。
这里可能有一个歧义的点，就是“拷贝到其它项目中使用”这个说法。依我看，go mod会自动安装你所需要库的依赖，它会在本地留下缓存信息。那么如果另一个项目中也需要使用 github.com/gin-gonic/gin，可以直接在代码中引用该依赖库，如下所示：
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
r := gin.Default()
// ...
}
只要之前已经在任意一个项目中使用了 go mod 命令下载过并缓存了 github.com/gin-gonic/gin，Go 会自动从缓存中加载依赖库代码，而不会重新下载依赖库代码到 $GOPATH/pkg/mod 目录下。
这种方式可以实现依赖库的共享，避免了多个项目同时拷贝依赖库代码，节省了磁盘空间。同时，如果需要使用不同的版本号，可以通过修改 go.mod 文件来实现对特定版本的依赖管理。
当你修改了 go.mod 文件中的依赖版本号或者添加了新的依赖项之后，可以使用 go mod tidy 命令来更新依赖关系，例如：
# 修改 go.mod 文件中的依赖版本号
go mod edit -require github.com/gin-gonic/gin@v1.7.2
# 更新依赖关系
go mod tidy
go mod tidy 会根据 go.mod 文件中的依赖关系自动下载并更新依赖库代码，以保持依赖关系的一致性，并且会删除未被引用的依赖项。
另外，如果你还希望移除某一个不再使用的依赖库，可以使用 go mod tidy -v 命令，它会输出垃圾收集的详细信息，包括哪些依赖项是被移除的。
Go的导包机制是什么？✌️
我的人生信条就是优雅，如何优雅地导包也是我所追求的。
在了解怎么导包之前，我们先需要了解包在Go里面的具象化的体现是什么？包和模块的区别是什么？
抛开语言，从软件角度考虑，我们认为子程序的集合称为包，包的集合称为模块，模块的集合称为子系统，子系统的集合称为系统。将这个说法往Go语言上代入，能发现我们编写的go文件就是子程序，go文件所在文件夹就是包，根目录的文件名就是模块名。这些具象化的体现还能从哪里看出来呢？其实还能从我们创建的文件中看出。
以这样的目录结构为例：
project/
|- go.mod
|- main.go
|- controllers/
|- user.go
|- admin.go
其中：
go.mod是模块文件，位于项目根目录。main.go是入口文件，位于项目根目录。controllers/目录下有两个文件user.go和admin.go
一般来说，当你查看go.mod文件时，能看到第一行写着
module project
这是告诉你模块名是project。如果以后你的代码开源了，别人想引用你的代码，首先就是要根据你的模块名再找对应的包名。这和其它语言引包的方式很相似。
module后面的模块名是允许修改的，你可以换成自定义的写法，通常的写法是域名+项目名。
再打开user.go，你能发现第一行写着
package controllers
这是指user.go是controllers包下面的一个子程序。
理清楚这些概念，我们还需要记住一个总纲：“导包其实就是寻址！导包其实就是寻址！导包其实就是寻址！”。重要的话说三遍！
还是以上面的目录结构为例，如果需要在 main.go 中导入 controllers/user.go 文件中的代码，可以使用相对路径 ./controllers 来导入 user.go 文件。
// main.go
package main
import "./controllers"
func main() {
// ...
}
对于模块，可以使用模块路径来引用相对路径下的文件。例如，假设你的模块路径为 example.com/mymodule，则可以在 main.go 中使用 example.com/mymodule/controllers 来引用相对路径下的 user.go 文件。
// main.go
package main
import "example.com/mymodule/controllers"
func main() {
// ...
}
需要注意的是，使用相对路径导入包时，包的实际路径是相对于当前文件所在的目录。如果在其他文件中也要使用相对路径导入 controllers/user.go，则需要将路径设置为相对于这个文件的路径。同时，相对路径只适用于模块内的代码，如果要在不同的模块之间导入代码，必须使用完整的包路径。
Go的测试代码怎么生成？👀
在 Go 中，我们可以通过创建测试文件来编写测试代码。测试文件应该遵循 Go 的命名规则，即在文件名后面加上 _test。例如，如果要编写一个名为 sum 的函数的测试代码，那么测试文件的文件名应该是 sum_test.go，而被测试的函数前面要加个Test前缀。
在测试文件中，我们可以使用 testing 包提供的一系列函数来编写测试代码，例如 testing.T 的 Error、Fail 和 Fatal 函数，以及 testing.B 的 ReportAllocs、ResetTimer 和 StopTimer 等函数。
下面是一个简单的测试示例，测试 sum 函数：
// sum_test.go
package main
import "testing"
func TestSum(t *testing.T) {
tables := []struct {
a, b, expected int
}{
{1, 1, 2},
{2, 2, 4},
{3, 3, 6},
}
for _, table := range tables {
result := sum(table.a, table.b)
if result != table.expected {
t.Errorf("Sum of %d + %d was incorrect, expected %d but received %d", table.a, table.b, table.expected, result)
}
}
}
在这个测试文件中，我们首先导入 testing 包，并定义了一个名为 TestSum 的测试函数。tables 定义了一个结构体切片，其中包含了一组要测试的参数和期望结果。我们遍历 tables 切片，逐一测试每组数据，判断计算结果是否和期望的结果一致。如果不一致，我们使用 t.Errorf 函数输出错误信息。这样就完成了一个简单的测试文件。
要运行测试文件，可以在项目根目录下使用 go test 命令运行。Go 会自动查找并运行所有的测试文件，并输出测试结果。测试结果中会显示测试用例的数量、测试是否通过以及每个测试用例的具体信息。例如：
$ go test
PASS
ok project 0.008s
在本示例中，我们只有一个测试用例，测试结果判定为 “ PASS ”，表示测试通过了。如果测试失败，则测试结果会判定为 “ FAIL ”，并输出具体的错误信息。
参考资料
https://tonybai.com/2022/04/28/the-standard-layout-of-go-project/
写的这么详细，诸位点个赞不过分吧！！！！