2.1.7. 目录结构规范¶
一个好的目录结构至少要满足以下几个要求:
1. 命名清晰
目录命名要清晰、简洁，不要太长，也不要太短，目录名要能清晰地表达出该目录实现的功能，并且目录名最好用单数。
一方面是因为单数足以说明这个目录的功能，另一方面可以统一规范，避免单复混用的情况。
2. 功能明确
一个目录所要实现的功能应该是明确的、并且在整个项目目录中具有很高的辨识度
也就是说，当需要新增一个功能时，我们能够非常清楚地知道把这个功能放在哪个目录下
3. 全面性
目录结构应该尽可能全面地包含研发过程中需要的功能，
例如文档、脚本、源码管理、API 实现、工具、第三方包、测试、编译产物等。
4. 可预测性
项目规模一定是从小到大的，所以一个好的目录结构应该能够在项目变大时，仍然保持之前的目录结构
5. 可扩展性
每个目录下存放了同类的功能，在项目变大时，这些目录应该可以存放更多同类功能
目录结构分为结构化目录结构和平铺式目录结构两种:
结构化目录结构主要用在 Go 应用中，相对来说比较复杂；
而平铺式目录结构主要用在 Go 包中，相对来说比较简单。
Go 社区比较推荐的结构化目录结构是 project-layout: https://blog.wu-boy.com/2019/11/how-to-define-the-golang-folder-layout/
目录结构示例:
├── api
│ ├── openapi
│ └── swagger
├── build
│ ├── ci
│ ├── docker
│ │ ├── iam-apiserver
│ │ └── iam-pump
│ ├── package
├── CHANGELOG
├── cmd
│ ├── iam-apiserver
│ │ └── apiserver.go
│ ├── iamctl
│ │ └── iamctl.go
│ └── iam-pump
│ └── pump.go
├── configs
├── CONTRIBUTING.md
├── deployments
├── docs
│ ├── devel
│ │ ├── en-US
│ │ └── zh-CN
│ ├── guide
│ │ ├── en-US
│ │ └── zh-CN
│ ├── images
│ └── README.md
├── examples
├── githooks
├── go.mod
├── go.sum
├── init
├── internal
│ ├── apiserver
│ │ ├── api
│ │ │ └── v1
│ │ │ └── user
│ │ ├── apiserver.go
│ │ ├── options
│ │ ├── service
│ │ ├── store
│ │ │ ├── mysql
│ │ │ ├── fake
│ │ └── testing
│ ├── authzserver
│ │ ├── api
│ │ │ └── v1
│ │ │ └── authorize
│ │ ├── options
│ │ ├── store
│ │ └── testing
│ ├── iamctl
│ │ ├── cmd
│ │ │ ├── completion
│ │ │ ├── user
│ │ └── util
│ ├── pkg
│ │ ├── code
│ │ ├── options
│ │ ├── server
│ │ ├── util
│ │ └── validation
├── LICENSE
├── Makefile
├── _output
│ ├── platforms
│ │ └── linux
│ │ └── amd64
├── pkg
│ ├── util
│ │ └── genutil
├── README.md
├── scripts
│ ├── lib
│ ├── make-rules
├── test
│ ├── testdata
├── third_party
│ └── forked
└── tools
一个 Go 项目包含 3 大部分：Go 应用 、项目管理和文档。所以，我们的项目目录也可以分为这 3 大类。同时，Go 应用又贯穿开发阶段、测试阶段和部署阶段，相应的应用类的目录，又可以按开发流程分为更小的子类。¶