这是Go应用程序项目的基本布局。不是核心Go开发团队定义的官方标准；但是，这是Go生态系统中的一组常见的历史和新兴项目布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强功能，以及任何足够大的实际应用程序共有的几个支持目录。
如果您想学习Go，或者您自己构建PoC或玩具项目，则此项目布局实在是太过分了。从一个非常简单的事情开始（一个main.go文件绰绰有余）。随着项目的增长，请记住，确保您的代码结构合理非常重要，否则最终将导致混乱的代码具有很多隐藏的依赖关系和全局状态。当有更多的人从事项目时，您将需要更多的结构。在那时候，重要的是要引入一种管理软件包/库的通用方法。当您拥有一个开源项目时，或者当您知道其他项目从项目存储库中导入代码时，拥有私有（aka内部）包和代码就很重要。克隆存储库，保留您需要的内容，然后删除其他所有内容！仅仅因为它在那里并不意味着您必须全部使用它。这些模式均未在每个项目中使用。甚至供应商模式也不是通用的。
有了Go 1.14，Go模块终于可以投入生产了。除非您有特定的原因不使用Go Modules，否则请使用Go Modules；如果这样做，则无需担心$ GOPATH和项目放置位置。回购中的基本go.mod文件假定您的项目托管在Github上，但这不是必需的。模块路径可以是任何东西，尽管第一个模块路径组件的名称中应带有点（当前版本的Go不再强制使用该点，但是，如果您使用的是稍旧的版本，则在构建失败时不会感到惊讶）它）。如果您想了解更多信息，请参见问题37554和32819。
该项目布局是有意通用的，并且不会尝试施加特定的Go包结构。
这是社区的努力。如果看到新的模式，或者认为需要更新现有模式之一，则打开一个问题。
如果需要命名，格式和样式方面的帮助，请先运行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 Style guideline for Go packages (rakyll/JBD) 有关其他背景信息，请参见转到项目布局。
有关命名和组织软件包以及其他代码结构建议的更多信息：
GopherCon EU 2018: Peter Bourgon - Best Practices for Industrial Programming GopherCon Russia 2018: Ashley McNamara + Brian Ketelsen - Go best practices.