Go的标准项目布局

Go的标准项目布局
这是Go应用程序项目的基本布局。它不是核心Go开发团队定义的官方标准;然而，它是Go生态系统 中一组常见的历史和新兴项目布局模式。其中一些模式比其他模式更受欢迎。它还有许多小的增强 功能，以及任何足够大的真实世界应用程序共有的几个支持目录。

如果您正在尝试学习Go或者您正在为自己构建PoC或不成熟的项目，那么这个项目布局是一种过度 杀伤力。从一些非常简单的东西开始（单个main.go文件绰绰有余）。随着项目的增长，请记住， 确保代码结构良好非常重要，否则终会出现带有大量隐藏依赖项和全局状态的混乱代码。当你有 更多的人参与这个项目时，你需要更多的结构。这就是介绍管理包/库的常用方法的重要性。当您有 一个开源项目或者您知道其他项目时，从您的项目存储库导入代码，这时私有（也就是内部）包和 代码很重要。克隆存储库，保留所需内容并删除其他所有内容！仅仅因为它在那里并不意味着你必 须全部使用它。在每个项目中都没有使用这些模式。甚至供应商模式也不普遍。

此项目布局是有意通用的，它不会尝试强加特定的Go包结构。

这篇文章这是社区的努力。如果您看到新模式或者您认为某个现有模式需要更新，请在git上提出问 题。

如果您需要有关命名，格式化和样式的帮助，请运行gofmt和golint。另外，请务必阅读这些Go代码 样式指南和建议：

https://talks.golang.org/2014/names.slide
https://golang.org/doc/effective_go.html#names
https://blog.golang.org/package­names
https://github.com/golang/go/wiki/CodeReviewComments

有关其他背景信息，请参阅Go Project Layout。

有关命名和组织包以及其他代码结构建议的更多信息：

GopherCon EU 2018: Peter Bourgon ­ Best Practices for Industrial Programming
GopherCon Russia 2018: Ashley McNamara + Brian Ketelsen ­ Go best practices.
GopherCon 2017: Edward Muller ­ Go Anti­Patterns
GopherCon 2018: Kat Zien ­ How Do You Structure Your Go Apps

Go的目录
 /cmd

该项目的主要应用。
每个应用程序的目录名称应与您要拥有的可执行文件的名称相匹配（例如，/ cmd / myapp）。
不要在应用程序目录中放入大量代码。如果您认为代码可以导入并在其他项目中使用，那么它应该 存在于/ pkg目录中。如果代码不可重用或者您不希望其他人重用它，请将该代码放在/ internal目录
中。你会惊讶于别人会做什么，所以要明确你的意图！
通常有一个小的main函数可以导入和调用/ internal和/ pkg目录中的代码而不是其他内容。 有关示例，请参阅/ cmd目录。

/internal

私有的应用程序和库的代码。这是您不希望其他人在其应用程序或库中导入的代码。
将您的实际应用程序代码放在/ internal / app目录（例如/ internal / app / myapp）和/ internal / pkg 目录中这些应用程序共享的代码（例如/ internal / pkg / myprivlib）。

/pkg

可以由外部应用程序使用的库代码（例如，/ pkg / mypubliclib）。其他项目将导入这些库，期望它 们可以工作，所以在你把东西放在这里之前要三思而后行:­)
当你的根目录包含许多非Go组件和目录时，它也可以在一个地方将Go代码分组，从而更容易运行 各种Go工具（如GopherCon EU 2018的工业编程佳实践中所述）。
如果要查看哪个流行的Go repos使用此项目布局模式，请参阅/ pkg目录。这是一种常见的布局模 式，但它并未被普遍接受，Go社区中的一些人不推荐它。

/vendor

应用程序依赖项（手动管理或由您喜欢的依赖管理工具（如dep）管理）。
如果要构建库，请不要提交应用程序依赖项。

服务应用程序目录
/api

OpenAPI / Swagger规范，JSON模式文件，协议定义文件。
有关示例，请参阅/ api目录。

Web应用程序目录
/web

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

常见应用程序目录
/configs

配置文件模板或默认配置。
将您的confd或consul­template模板文件放在这里。

/init

系统初始化（systemd，upstart，sysv）和进程管理器/主管（runit，supervisord）配置。

/scripts

脚本执行各种构建，安装，分析等操作。
这些脚本使根级Makefile保持简洁（例如， https：//github.com/hashicorp/terraform/blob/master/Makefile）。
有关示例，请参阅/ scripts目录。

/build

打包和持续集成。
将您的云（AMI），容器（Docker），OS（deb，rpm，pkg）包配置和脚本放在/ build / package 目录中。
将CI（travis，circle，drone）配置和脚本放在/ build / ci目录中。请注意，某些CI工具（例如， Travis CI）对其配置文件的位置非常挑剔。尝试将配置文件放在/ build / ci目录中，将它们链接到CI 工具所期望的位置（如果可能）。

/deployments

IaaS，PaaS，系统和容器编排部署配置和模板（docker­compose，kubernetes / helm，mesos， terraform，bosh）。

/test

其他外部测试应用和测试数据。您可以随意构建/ test目录。对于更大的项目，有一个数据子目录是 有意义的。例如，如果需要Go忽略该目录中的内容，可以使用/ test / data或/ test / testdata。请注 意，Go也会忽略以“.”开头的目录或文件。或“_”，因此您在命名测试数据目录方面具有更大的灵活 性。
有关示例，请参阅/ test目录。

其他目录
/docs

设计和用户文档（除了你的godoc生成的文档）。
有关示例，请参阅/ docs目录。

/tools

该项目的支持工具。请注意，这些工具可以从/ pkg和/ internal目录导入代码。
有关示例，请参见/ tools目录。

/examples

应用程序和/或公共库的示例。
有关示例，请参阅/ examples目录。

/third_party

外部帮助工具，分叉代码和其他第三方实用程序（例如，Swagger UI）。

/githooks

Git hooks.

/assets

与您的存储库一起使用的其他资产（images, logos, etc）。

/website

如果您不使用Github页面，这是放置项目的网站数据的地方。
有关示例，请参阅/ website目录。

你不应该有的目录
/src

一些Go项目确实有一个src文件夹，但它通常发生在开发人员来自Java世界时，它是一种常见的模 式。如果您可以帮助自己尝试不采用此Java模式。你真的不希望你的Go代码或Go项目看起来像 Java :­)
不要将项目级别/ src目录与Go用于其工作空间的/ src目录混淆，如如何编写Go代码中所述。 环境变量指向您的（当前）工作空间（默认情况下，它指向非 系统上的 HOME / go）。此工作空间包括顶级/ pkg，/ bin和/ src目录。您的实际项目终成为/ src下的子目录，因此 如果项目中有/ src目录，项目路径将如下所示：/ some / path / to / workspace / src / your_project / src / your_code。请注意，使用Go 1.11可以将项目置于GOPATH之外，但这并不意味着使用此布 局模式是个好主意。

Badges
Go Report Card­它将使用gofmt，go vet，gocyclo，golint，ineffassign，license和misspell扫描你 的代码。将github.com/golang­standards/project­layout替换为您的项目参考。
GoDoc ­ 它将提供GoDoc生成文档的在线版本。更改链接以指向您的项目。
Release­它将显示项目的新版本号。更改github链接以指向您的项目。

脚注

具有可复用的配置，脚本和代码的更具见解性的项目模板是WIP。