Golang项目目录结构最佳实践

Golang项目目录结构最佳实践 谁能解释一下标准的Go项目文件夹结构（工业级）是怎样的？

6 回复

这就是我遵循的那个。

更多关于Golang项目目录结构最佳实践的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


很高兴听到这个消息。我刚刚在网上搜索了一下，并发布了一个看起来不错的项目链接。当然，有很多博客文章讨论这个问题，也有很多GitHub项目提出了结构方案。

我怀疑是否存在一个“工业级”的项目结构，只有好的和不好的之分。

除了文档中指定的标准文件夹外，虽然没有另一个行业级别的标准，但有一些方案可以满足部分用户的需求。你可以考虑其中一些非常流行的方案，但如果符合你的需求，也可以（在一定的限度内）自由使用你自己的结构。

一次简单的网络搜索会找到各种类似的结果：

GitHub

golang-standards/project-layout

头像

标准 Go 项目布局。通过在 GitHub 上创建账户来为 golang-standards/project-layout 的开发做出贡献。

我认为我的做法与那个足够不同，我应该修改我的评论。

我确实遵循这样的惯例：包应该放在 /pkg 目录下，文档放在 /docs 目录下，命令行应用程序放在 /cmd 目录下。然而，我使用 /build 作为一个被 .gitignore 忽略的目录，用于存放构建好的二进制文件和其他文件；使用 /images 存放预构建的镜像；使用 /data 存放静态数据文件。

在工业级Go项目中，典型的目录结构遵循标准布局，同时根据项目规模进行适当调整。以下是一个常见的结构示例：

project/
├── cmd/
│   ├── api/
│   │   └── main.go
│   └── cli/
│       └── main.go
├── internal/
│   ├── handler/
│   ├── service/
│   └── repository/
├── pkg/
│   ├── utils/
│   └── models/
├── api/
│   └── openapi.yaml
├── configs/
├── deployments/
├── scripts/
├── test/
├── go.mod
├── go.sum
└── Makefile

关键目录说明：

  1. cmd/: 包含应用程序的入口点，每个子目录对应一个可执行文件
// cmd/api/main.go
package main

import "project/internal/handler"

func main() {
    handler.StartServer()
}
  1. internal/: 私有应用程序代码，外部项目无法导入
// internal/handler/user.go
package handler

type UserHandler struct {
    service UserService
}

func (h *UserHandler) CreateUser(c *gin.Context) {
    // 处理逻辑
}
  1. pkg/: 公共库代码，可供外部项目导入
// pkg/utils/validator.go
package utils

func ValidateEmail(email string) bool {
    // 验证逻辑
    return true
}

  1. api/: API定义文件（OpenAPI/Swagger等）

  2. configs/: 配置文件模板或默认配置

  3. test/: 额外的测试文件和数据

实际项目示例：

// 模块导入示例
import (
    "project/internal/service"
    "project/pkg/utils"
    "project/pkg/models"
)

这种结构清晰分离了关注点，遵循Go的包管理原则，便于团队协作和代码维护。

回到顶部