以构建二进制可执行文件为目的

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 的文件，以便于在本地进行测试和调试。但是该文件不应该被提交到源代码管理系统中，它只是用于开发过程中的临时文件。