林业建设协会网站,wordpress建立购物网站,长沙百度网络推广,基于jsp的精品课程网站建设这里写自定义目录标题Go项目本身的目录结构Go语言项目典型目录结构GO语言项目最小标准目录结构可执行的Go语言项目目录结构库的Go语言项目目录结构关于internal目录总结参考文章每当我们写一个非hello world实用程序的Go程序或库时#xff0c;我们都会在项目结构、代码风格和标…
这里写自定义目录标题Go项目本身的目录结构Go语言项目典型目录结构GO语言项目最小标准目录结构可执行的Go语言项目目录结构库的Go语言项目目录结构关于internal目录总结参考文章每当我们写一个非hello world实用程序的Go程序或库时我们都会在项目结构、代码风格和标识符命名这三个“门槛”面前折腾很久甚至得不到满意的答案。
在本文中我们将详细介绍如何跨过Go项目结构的“门槛”帮助您更快地进入Go语言的核心腹地提高学习效率。
除非是像hello world这样简单的程序否则每当我们写实用程序或库时都会遇到使用什么项目结构的问题通常一个Go项目对应一个repository。在Go中项目结构也很重要因为它决定了项目内部包的布局和包依赖关系也影响了外部项目对项目内包的依赖和引用。
Go项目本身的目录结构
我们来看看Go语言本身的项目结构世界上第一个Go项目。
Go项目的项目结构从1.0版本发布开始就非常稳定Go项目的顶层结构至今基本没有变化。截至go project commit 1e3ffb0c (2019.5.14)go项目结构如下。
$ tree -LF 1 ~/go/src/github.com/golang/go
./go
├── api/
├── AUTHORS
├── CONTRIBUTING.md
├── CONTRIBUTORS
├── doc/
├── favicon.ico
├── lib/
├── LICENSE
├── misc/
├── PATENTS
├── README.md
├── robots.txt
├── src/
└── test/作为Go的“创始项目”其项目结构布局对后续其他Go项目具有重要参考意义尤其是早期Go项目中src目录下的结构被Go社区广泛用作模板Go 应用程序项目结构。我们以早期Go 1.3版本的src目录下的结构为例。
$ tree -LF 1 ./src
./src
├── all.bash*
├── all.bat
├── all.rc*
├── clean.bash*
├── clean.bat
├── clean.rc*
├── cmd/
├── lib9/
├── libbio/
├── liblink/
├── make.bash*
├── make.bat
├── Make.dist
├── make.rc*
├── nacltest.bash*
├── pkg/
├── race.bash*
├── race.bat
├── run.bash*
├── run.bat
├── run.rc*
└── sudo.bash*关于上面src目录下面的结构我总结了三个特点。 代码构建的脚本源文件放在src下的顶层目录下。 src 下的二级目录 cmd 存放了 go 工具链相关的可执行文件如go、gofmt 等及其主要包源文件的主目录。
$ tree -LF 1 ./cmd
./cmd
...
├── 6a/
├── 6c/
├── 6g/
...
├── cc/
├── cgo/
├── dist/
├── fix/
├── gc/
├── go/
├── gofmt/
├── ld/
├── nm/
├── objdump/
├── pack/
└── yacc/src下的二级目录pkg存放着上面cmd下各个工具链所依赖的packages、go runtime、go standard library的源文件。
$ tree -LF 1 ./pkg
./pkg
...
├── flag/
├── fmt/
├── go/
├── io/
├── log/
├── math/
...
├── syscall/
├── testing/
├── text/
├── time/
├── unicode/
└── unsafe/从 Go 1.3 版本至今Go 项目下的 src 目录发生了一些结构上的变化。
Go 1.4 从 Go 源代码树中的 src/pkg/xxx 中删除了 pkg 级别而是直接使用 src/xxx。Go 1.4 在 src 下增加了 internal 目录用来存放不能外部导入的只供 Go 项目使用的包。Go 1.6 在 src 下增加了 vendor 目录但是 Go 项目本身真正启用了 Go 1.7 中的 vendor 机制。vendor目录下存放着Go项目自身对外部项目的依赖主要是golang.org/x下的包包括net、text、crypto等。该目录下的包随着每个Go版本的发布而更新。Go 1.13版本在src下增加了go.mod和go.num实现了go项目本身go module的迁移。go项目中的所有包都放在了std模块下其依赖仍然是golang.org/x下的各种包
// Go 1.13版本go项目src下面的go.mod
module stdgo 1.12require (golang.org/x/crypto v0.0.0-20200124225646-8b5121be2f68golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7golang.org/x/sys v0.0.0-20190529130038-5219a1e1c5f8 // indirectgolang.org/x/text v0.3.2 // indirect
)这是最新 Go 1.16 版本的 src 目录中的完整布局。
├── Make.dist
├── README.vendor
├── all.bash*
├── all.bat
├── all.rc*
├── bootstrap.bash*
├── buildall.bash*
├── clean.bash*
├── clean.bat
├── clean.rc*
├── cmd/
├── cmp.bash
├── go.mod
├── go.sum
├── internal/
├── make.bash*
├── make.bat
├── make.rc*
├── race.bash*
├── race.bat
├── run.bash*
├── run.bat
├── run.rc*
├── testdata/
...
└── vendor/Go语言项目典型目录结构
GO语言项目最小标准目录结构
一个Go应用项目结构的标准布局是什么样子的Go官方团队从来没有给出过一个参考标准。不过作为Go语言项目的技术负责人 Russ Cox在开源项目的一期中给出了他对Go项目结构最小标准布局的思考。他认为Go项目的最低标准布局应该如下。
// 在Go项目仓库根路径下- go.mod
- LICENSE
- xx.go
- yy.go
...or- go.mod
- LICENSE
- package1- package1.go
- package2- package2.go
...至于 pkg、cmd、docs这些目录不应该是 Go 项目的标准结构的一部分或者至少不需要。相信 Russ Cox 给出的最小标准布局与 Go 的“简单”哲学是一致的足够灵活可以满足各种 Go 项目的需求。
然而在 Russ Cox 详细阐述最低标准之前Go 社区处于“非标准”状态早期 Go 语言自身的项目结构对现有大量 Go 开源项目的影响依然持久。对于更大的 Go 应用程序我们势必会扩展“最小标准布局”。这个扩展显然不会盲目但还是会参考Go语言项目自身的结构布局所以我们有以下非官方标准建议的结构布局。
可执行的Go语言项目目录结构
基于Go语言项目本身的早期结构及其后续演变Go社区经过多年的Go语言实践积累逐渐形成了符合Russ Cox最小标准布局的典型项目结构如下图所示。 以上是一个典型的支持构建二进制可执行文件的Go项目结构在cmd下我们分别看一下各个重要目录的用途。 cmd目录存放项目要编译构建的可执行文件对应的主包源文件。如果有多个可执行文件要构建则每个可执行文件的主包放在单独的子目录下如图中的app1和app2cmd目录下每个app的主包将整个项目的依赖连接在一起而且一般来说主包应该是非常简洁的。我们会在main包中做一些命令行参数解析、资源初始化、日志工具初始化、数据库连接初始化等之后我们会将程序的执行权交给更高级的执行控制对象也有一些go项目把cmd的名字改成了app但是它的实用性并没有改变。 pkg目录项目本身要用到的也是主包对应的可执行文件依赖的库文件同时该目录下的包也可以被外部项目引用作为项目导出包的“聚合”也有一些项目会 pkg 名称为 lib但目录用途保持不变因为Go语言项目在1.4版本去掉了pkg目录所以有一些项目直接把包放在项目的根路径下但是我觉得对于一些比较大的项目包太多会成为顶层目录该项目不够简洁和“拥挤”。对于复杂的 Go 项目我建议保留 pkg 目录。 Makefile这里的Makefile是项目构建工具使用的脚本的“代表”它可以代表任何第三方构建工具使用的脚本。对于大型项目来说似乎是必不可少的。在一个典型的Go项目中项目构建工具的脚本通常放在项目的顶层目录下比如这里的Makefile对于构建脚本较多的项目也可以创建构建目录将构建脚本的规则属性文件和子构建脚本放入其中。 go.mod和go.sum用于Go语言包依赖管理的配置文件。Go 1.11 引入了 go modulesgo module 在 Go 1.16 成为了默认的依赖包管理和构建机制。所以对于新的 Go 项目我们推荐使用 go modules 来进行包依赖管理。对于没有使用go modules进行包管理的项目可能主要是使用go 1.11以前版本的go项目可以换成dep的Gopkg.toml和Gopkg.lock或者glide的glide.yaml和glide.lock等. vendor 目录可选vendor 是 Go 1.5 引入的机制用于在项目本地缓存版本特定的依赖包在引入 go modules 机制之前可以实现基于 vendor 的可重现构建以确保从相同构建的可执行文件源代码是等价的。go modules 本身可以在没有供应商的情况下实现可重现的构建。modules 本身可以在不需要 vendor 的情况下实现可重现的构建但是 go modules 机制还保留了 vendor 目录go mod vendor 在 vendor 下生成依赖项go build -modvendor 启用基于 vendor 的构建所以这里的 vendor 目录作为可选目录。一般我们只将vendor目录保留在项目的根目录下否则会造成依赖选择上不必要的复杂性。
Go 1.11 引入了一个模块作为属于同一版本控制单元的包的集合。虽然 Go 支持项目/存储库中的多个模块但这种管理方法可能会带来比一定比例的代码重复更多的复杂性。因此如果项目结构中存在版本控制“分歧”例如 app1 和 app2 版本并不总是同步那么我建议将项目拆分为多个项目存储库每个项目都是一个单独的模块用于单独的版本控制和演进.
库的Go语言项目目录结构
Go 1.4 发布时Go 语言项目本身就去掉了 src 下的 pkg 层。这种结构变化对仅为库目的而构建的 Go 库类型项目的结构有一些影响。我们来看一个典型的 Go 库类型项目的结构如下图所示。 我们看到库类型的项目结构也兼容 Go 项目的最低标准布局但比旨在构建二进制可执行文件的 Go 项目更简单。
删除了cmd和pkg子目录由于该库只是一个组件库因此无需保留存放二进制文件主要包源文件的cmd目录由于 Go 库项目的初衷是将 API 暴露给外界开源或内部组织因此没有必要将其聚合在 pkg 目录下。vendor不再可选对于库类型的项目我们不建议在项目中放置vendor目录来缓存库自身的第三方依赖库项目应该只通过 go.mod或其他包依赖管理工具的清单文件明确说明项目依赖的模块或包以及版本要求。
关于internal目录
对于上述任何类型的Go项目对于不想暴露给外部引用而只供内部使用的包可以通过Go 1.4引入的内部包机制来实现项目结构。对于库项目最简单的方法是在顶层添加一个内部目录将所有不想暴露给外部的包都放在该目录下例如项目中的 ilib1 和 ilib2下面的结构。
// 带internal的Go库项目结构
$tree -F ./chapter2/sources/GoLibProj
GoLibProj
├── LICENSE
├── Makefile
├── README.md
├── go.mod
├── internal/
│ ├── ilib1/
│ └── ilib2/
├── lib.go
├── lib1/
│ └── lib1.go
└── lib2/└── lib2.go这样根据go内部机制的原理内部目录的ilib1和ilib2可以被其他目录如lib.go、lib1/lib1.go等的代码导入使用GoLibProj目录为根目录但不是通过 GoLibProj 目录之外的代码。这允许选择性地公开 API 包。当然 internal 可以放在项目结构中的任何目录级别但是项目结构设计者清楚什么要暴露给外部代码以及什么只能在兄弟目录或子目录中使用是至关重要的。
对于旨在构建二进制可执行类型的项目我们还可以将不想暴露给外部的包聚合到项目顶层路径的internal下呼应暴露给包的聚合目录pkg外部。
总结
这篇文章详细介绍了Go语言项目结构布局的历史和Go项目结构的事实标准。本文中构建二进制可执行文件类型和库类型的两个项目参考结构经过多年的实践被Go社区认可并广泛使用并且兼容Russ Cox提出的Go项目最小标准布局具有参考价值对于稍大的 Go 项目。然而它们不是必需的在 Go 语言的早期将所有源文件放在位于项目根目录的根包中的做法在一些小型项目中同样有效。
对于旨在构建二进制可执行类型的项目受 Go 1.4 项目结构的影响删除 pkg 层次结构也是许多项目选择的结构布局。
上述参考项目结构类似于产品设计和开发领域的“最小可行产品”mvp的思想开发者可以根据自己的实际需要在这样一个最小“项目结构核心”的基础上进行扩展。 By 极客Furzoom
参考文章
go project layout
