Go工程目录

一、概述

• 命名清晰：名称要清晰、简洁，不要太长也不要太短，要能清晰地表达出该目录实现的功能，并且最好用单数。一方面是因为单数足以说明这个目录的功能，另一方面可以统一规范，避免单复混用的情况。
• 功能明确：它所要实现的功能应该是明确的、并且在整个项目目录中具有很高的辨识度。也就是说，当需要新增一个功能时，我们能够非常清楚地知道把这个功能放在哪个目录下。
• 全面性：目录结构应该尽可能全面地包含研发过程中需要的功能，例如文档、脚本、源码管理、API 实现、工具、第三方包、测试、编译产物等。
• 可预测性：项目规模一定是从小到大的，所以一个好的目录结构应该能够在项目变大时，仍然保持之前的目录结构。
• 可扩展性：每个目录下存放了同类的功能，在项目变大时，这些目录应该可以存放更多同类功能。

• 平铺式目录结构，主要用在Go包中，相对来说比较简单。
  平铺方式就是在项目的根目录下存放项目的代码，整个目录结构看起来更像是一层的，这
  种方式在很多框架/库中存在，使用这种方式的好处是引用路径长度明显减少。比如：github.com/marmotedu/log/pkg/options可以缩短为github.com/marmotedu/log/options。
  例如，log包github.com/golang/glog就是平铺式的，目录如下：

$ ls glog/
glog_file.go  glog.go  glog_test.go  LICENSE  README

• 结构化目录结构，主要用在Go应用中，相对来说比较复杂。

二、结构化目录结构

┌── build
│   ├── ci
│   ├── docker
│   │   ├── proc_1
│   │   └── proc_2
│   └── package
├── cmd
│   ├── proc_1
│   │   └── main.go
│   └── proc_2
│       └── main.go
├── doc
│   ├── devel
│   │   ├── en-US
│   │   └── zh-CN
│   ├── guide
│   │   ├── en-US
│   │   └── zh-CN
│   ├── image
│   └── README.md
├── example
├── internal
│   ├── app
│   │   ├── proc_1
│   │   │   ├── command
│   │   │   ├── config
│   │   │   ├── constants
│   │   │   ├── db
│   │   │   ├── model
│   │   │   └── service
│   │   └── proc_2
│   │       ├── command
│   │       ├── config
│   │       ├── constant
│   │       ├── db
│   │       ├── model
│   │       └── service
│   └── pkg
│       ├── log
│       └── util
│           └── util.go
├── pkg
├── vendor
├── test
├── tool
├── CHANGELOG
├── CONTRIBUTING.md
├── go.mod
├── go.sum
├── LICENSE
└── README.md

/build

/build/ci

存放CI（travis，circle，drone）的配置文件和脚本。

/build/docker

存放子项目各个组件的Dockerfile文件。

/build/package

存放容器（Docker）、系统（deb, rpm, pkg）的包配置和脚本。

/cmd

/doc

存放相关文档。

/example

存放示例代码。

/internal

存放项目的私有代码和库代码。

/internal/app

/internal/pkg

/pkg

/vendor

项目依赖，可通过go mod vendor创建。需要注意的是，如果是一个Go库，不要提交vendor依赖包。

/test

用于存放其他外部测试应用和测试数据。

/tool

存放这个项目的支持工具。