golang项目目录结构规范与最佳实践插件库golang-standards/project-layout的使用

Golang项目目录结构规范与最佳实践插件库golang-standards/project-layout的使用

概述

这是Go应用程序项目的基本布局。请注意，它在内容上是基本的，因为它只关注一般布局而不是内部内容。它也是基础性的，因为它非常高级，没有详细说明如何进一步构建项目。

目录结构说明

/cmd

项目的主要应用程序。每个应用程序的目录名称应与您希望拥有的可执行文件名称匹配（例如/cmd/myapp）。

示例：

/cmd
  /myapp
    main.go

/internal

私有应用程序和库代码。这是您不希望其他人在其应用程序或库中导入的代码。

示例：

/internal
  /app
    /myapp
      service.go
  /pkg
    /myprivlib
      internal.go

/pkg

外部应用程序可以使用的库代码（例如/pkg/mypubliclib）。

示例：

/pkg
  /mypubliclib
    public.go

/vendor

应用程序依赖项（手动管理或使用您喜欢的依赖项管理工具）。

/api

OpenAPI/Swagger规范，JSON模式文件，协议定义文件。

/web

Web应用程序特定组件：静态Web资产，服务器端模板和SPA。

/configs

配置文件模板或默认配置。

/scripts

执行各种构建、安装、分析等操作的脚本。

/build

打包和持续集成。

/deployments

IaaS、PaaS、系统和容器编排部署配置和模板。

/test

额外的外部测试应用程序和测试数据。

/docs

设计和用户文档。

/tools

项目的支持工具。

/examples

您的应用程序和/或公共库的示例。

完整示例项目结构

myproject/
├── cmd/
│   └── myapp/
│       └── main.go
├── internal/
│   ├── app/
│   │   └── myapp/
│   │       └── service.go
│   └── pkg/
│       └── myprivlib/
│           └── internal.go
├── pkg/
│   └── mypubliclib/
│       └── public.go
├── api/
│   └── openapi.yaml
├── configs/
│   └── config.yaml
├── scripts/
│   └── build.sh
├── test/
│   └── integration/
│       └── integration_test.go
├── go.mod
└── go.sum

注意事项

  1. 对于小型项目或学习Go，这种布局可能过于复杂。可以从简单的main.go文件和go.mod开始。

  2. 这不是Go核心开发团队定义的官方标准，而是Go生态系统中常见的历史和新兴项目布局模式。

  3. 使用Go 1.14及以上版本时，建议使用Go Modules。


更多关于golang项目目录结构规范与最佳实践插件库golang-standards/project-layout的使用的实战教程也可以访问 https://www.itying.com/category-94-b0.html

1 回复

更多关于golang项目目录结构规范与最佳实践插件库golang-standards/project-layout的使用的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


Golang项目目录结构规范与最佳实践

标准项目目录结构

Golang社区有一个被广泛认可的项目目录结构标准，即golang-standards/project-layout。这个项目提供了一套合理的目录结构规范，适用于大多数Go项目。

核心目录结构

├── /cmd
├── /internal
├── /pkg
├── /api
├── /web
├── /configs
├── /init
├── /scripts
├── /build
├── /deployments
├── /test
├── /vendor
├── go.mod
├── go.sum
└── README.md

关键目录详解

1. /cmd - 主应用程序目录

包含项目的主要可执行文件，每个子目录对应一个主程序。

示例结构：

/cmd
  ├── app1
  │   └── main.go
  └── app2
      └── main.go

2. /internal - 私有代码

包含项目私有代码，外部项目无法导入这些包。

// internal/app/foo/foo.go
package foo

func Bar() string {
    return "internal bar"
}

3. /pkg - 公共库代码

包含可以被外部项目导入的公共库代码。

// pkg/mylib/mylib.go
package mylib

func PublicFunc() string {
    return "public function"
}

4. /api - API定义

包含API协议定义文件，如Swagger/OpenAPI、gRPC等。

最佳实践

1. 使用go mod管理依赖

go mod init github.com/yourname/yourproject

2. 合理的包划分

  • 按功能而非类型划分包
  • 避免循环依赖
  • 保持包小而专注

3. 测试结构

/test
  ├── integration
  └── unit

示例测试代码：

// pkg/mylib/mylib_test.go
package mylib_test

import (
    "testing"
    "github.com/yourname/yourproject/pkg/mylib"
)

func TestPublicFunc(t *testing.T) {
    got := mylib.PublicFunc()
    if got != "public function" {
        t.Errorf("expected 'public function', got %s", got)
    }
}

使用project-layout模板

  1. 克隆模板仓库：
git clone https://github.com/golang-standards/project-layout.git myproject
cd myproject
rm -rf .git
  1. 初始化Go模块：
go mod init github.com/yourname/myproject
  1. 开始开发：
mkdir -p cmd/myapp internal/app pkg/mylib

实际项目示例

以下是一个简单的Web服务项目结构示例：

/mywebapp
├── /cmd
│   └── /server
│       └── main.go
├── /internal
│   ├── /app
│   │   ├── /handlers
│   │   │   └── user.go
│   │   └── /models
│   │       └── user.go
│   └── /config
│       └── config.go
├── /pkg
│   └── /utils
│       └── validator.go
├── /api
│   └── swagger.yaml
├── /configs
│   └── app.yaml
├── /test
│   ├── /integration
│   └── /unit
│       └── utils_test.go
├── go.mod
├── go.sum
└── README.md

cmd/server/main.go示例：

package main

import (
	"fmt"
	"log"
	"net/http"
	
	"github.com/yourname/mywebapp/internal/app/handlers"
	"github.com/yourname/mywebapp/internal/config"
)

func main() {
	cfg := config.Load()
	
	http.HandleFunc("/users", handlers.UserHandler)
	
	log.Printf("Starting server on %s", cfg.ServerAddress)
	log.Fatal(http.ListenAndServe(cfg.ServerAddress, nil))
}

总结

遵循golang-standards/project-layout规范可以带来以下好处：

  1. 提高代码可维护性
  2. 便于团队协作
  3. 使项目结构更清晰
  4. 方便代码复用
  5. 更好的测试组织

根据项目实际需求，可以适当调整目录结构，但保持核心原则不变。对于小型项目，可以简化结构，但对于中大型项目，建议遵循完整的规范。

回到顶部