以构建二进制可执行文件为目的
project-name/
├── cmd/
│ ├── main.go
│ └── ...
├── internal/
│ ├── pkg1/
│ │ ├── file1.go
│ │ └── ...
│ ├── pkg2/
│ │ ├── file2.go
│ │ └── ...
│ └── ...
├── pkg/
│ ├── lib1/
│ │ ├── file1.go
│ │ └── ...
│ ├── lib2/
│ │ ├── file2.go
│ │ └── ...
│ └── ...
├── vendor/
├── go.mod
├── go.sum
└── README.md
其中各个目录的含义如下：
cmd/：该目录包含一个或多个主要的命令行程序。每个子目录下应该是该命令行程序的源代码和相关资源。internal/：该目录包含项目中使用的内部库和工具。这些库只能被该项目的其他代码引用，而不能被其他项目引用。pkg/：该目录包含可以被其他项目使用的库。通常情况下，应该为每个子目录创建一个独立的包（package）。vendor/：该目录包含所有依赖的第三方库。这些库的版本应该在go.mod文件中指定，并且可以在本地进行缓存以避免重复下载。go.mod：该文件用于记录项目的依赖关系和版本信息。go.sum：该文件包含所有依赖库的 SHA 校验和，用于保证依赖库的完整性。README.md：该文件包含项目的简要描述和使用说明。 随着 Go Modules 的推出，已经不推荐使用vendor目录来管理第三方包的依赖。如果在项目中使用了 Go Modules，可以直接执行go mod tidy在go.mod文件中记录项目依赖，并让 Go 自动管理它们。这样做的好处是：- 依赖项统一管理：通过
go.mod文件管理依赖项，可以轻松地查看和更新所有依赖项的版本。 - 简化开发：使用
go.mod文件可以减少手动下载和复制依赖项的过程，从而简化开发流程。 - 减少存储空间：由于
vendor目录中有许多重复的依赖项，因此使用 Go Modules 可以减少存储空间的占用。
如果项目需要支持旧版的 Go 或者项目依赖于一些不支持 Go Modules 的第三方库，那么仍然可以使用 vendor 目录来管理依赖项。执行 go mod vendor 后，Go 会检查当前项目中使用的所有第三方库，生成 vendor 下的依赖包。执行 go build -mod=vendor 后，可以实现基于 vendor 的构建。
以只构建库为目的的项目结构
project-name/
|-- example/ # 示例代码或应用程序
|-- internal/ # 内部代码，不可导出
|-- pkg/ # 可以被其他项目导入的库代码
|-- README.md # 项目说明和文档
|-- go.mod # Go模块文件
|-- go.sum # Go模块依赖文件
|-- LICENSE # 代码许可证
`-- main.go # 仅用于开发中的二进制文件
其中各个目录的含义如下：
example/：该目录通常包含库的示例代码。internal/：该目录包含项目的内部代码，这些代码不能被其他项目导入。pkg/：该目录包含可以被其他项目导入的库代码。README.md：该文件通常用于提供有关项目的信息和文档。go.mod和go.sum：用于管理 Go 模块和依赖项。LICENSE：该文件提供代码的许可证信息。 在开发过程中，可能需要在根目录下创建一个名为main.go的文件，以便于在本地进行测试和调试。但是该文件不应该被提交到源代码管理系统中，它只是用于开发过程中的临时文件。
