[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-582":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":16,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":18,"compositeScore":19,"rankGlobal":9,"rankLanguage":9,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":30,"readmeContent":31,"aiSummary":32,"trendingCount":15,"starSnapshotCount":15,"syncStatus":33,"lastSyncTime":34,"discoverSource":35},582,"project-layout","golang-standards\u002Fproject-layout","golang-standards","Standard Go Project Layout",null,"Makefile",56098,5444,596,72,0,25,144,12,45,"Other",false,"master",true,[25,26,27,28,29],"go","golang","project-structure","project-template","standards","2026-06-12 02:00:15","# Standard Go Project Layout\n\nTranslations:\n\n* [한국어 문서](README_ko.md)\n* [简体中文](README_zh.md)\n* [正體中文](README_zh-TW.md)\n* [简体中文](README_zh-CN.md) - ???\n* [Français](README_fr.md)\n* [日本語](README_ja.md)\n* [Português](README_ptBR.md)\n* [Español](README_es.md)\n* [Română](README_ro.md)\n* [Русский](README_ru.md)\n* [Türkçe](README_tr.md)\n* [Italiano](README_it.md)\n* [Tiếng Việt](README_vi.md)\n* [Українська](README_ua.md)\n* [Indonesian](README_id.md)\n* [हिन्दी](README_hi.md)\n* [فارسی](README_fa.md)\n* [Беларуская](README_be.md)\n* [বাংলা](README_bn.md)\n\n## Overview\n\nThis is a basic layout for Go application projects. Note that it's basic in terms of content because it's focusing only on the general layout and not what you have inside. It's also basic because it's very high level and it doesn't go into great details in terms of how you can structure your project even further. For example, it doesn't try to cover the project structure you'd have with something like Clean Architecture.\n\nThis is **`NOT an official standard defined by the core Go dev team`**. This is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application. Note that the **core Go team provides a great set of general guidelines about structuring Go projects** and what it means for your project when it's imported and when it's installed. See the [`Organizing a Go module`](https:\u002F\u002Fgo.dev\u002Fdoc\u002Fmodules\u002Flayout) page in the official Go docs for more details. It includes the `internal` and `cmd` directory patterns (described below) and other useful information.\n\n**`If you are trying to learn Go or if you are building a PoC or a simple project for yourself this project layout is an overkill. Start with something really simple instead (a single `main.go` file and `go.mod` is more than enough).`** As your project grows keep in mind that it'll be important to make sure your code is well structured otherwise you'll end up with a messy code with lots of hidden dependencies and global state. When you have more people working on the project you'll need even more structure. That's when it's important to introduce a common way to manage packages\u002Flibraries. When you have an open source project or when you know other projects import the code from your project repository that's when it's important to have private (aka `internal`) packages and code. Clone the repository, keep what you need and delete everything else! Just because it's there it doesn't mean you have to use it all. None of these patterns are used in every single project. Even the `vendor` pattern is not universal.\n\nWith Go 1.14 [`Go Modules`](https:\u002F\u002Fgo.dev\u002Fwiki\u002FModules) are finally ready for production. Use [`Go Modules`](https:\u002F\u002Fblog.golang.org\u002Fusing-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https:\u002F\u002Fgithub.com\u002Fgolang\u002Fgo\u002Fissues\u002F37554) and [`32819`](https:\u002F\u002Fgithub.com\u002Fgolang\u002Fgo\u002Fissues\u002F32819) if you want to know more about it.\n\nThis project layout is intentionally generic and it doesn't try to impose a specific Go package structure.\n\nThis is a community effort. Open an issue if you see a new pattern or if you think one of the existing patterns needs to be updated.\n\nIf you need help with naming, formatting and style start by running [`gofmt`](https:\u002F\u002Fgolang.org\u002Fcmd\u002Fgofmt\u002F) and [`staticcheck`](https:\u002F\u002Fgithub.com\u002Fdominikh\u002Fgo-tools\u002Ftree\u002Fmaster\u002Fcmd\u002Fstaticcheck). The previous standard linter, golint, is now deprecated and not maintained; use of a maintained linter such as staticcheck is recommended. Also make sure to read these Go code style guidelines and recommendations:\n* https:\u002F\u002Ftalks.golang.org\u002F2014\u002Fnames.slide\n* https:\u002F\u002Fgolang.org\u002Fdoc\u002Feffective_go.html#names\n* https:\u002F\u002Fblog.golang.org\u002Fpackage-names\n* https:\u002F\u002Fgo.dev\u002Fwiki\u002FCodeReviewComments\n* [Style guideline for Go packages](https:\u002F\u002Fweb.archive.org\u002Fweb\u002F20260110162648\u002Fhttps:\u002F\u002Frakyll.org\u002Fstyle-packages\u002F) (rakyll\u002FJBD)\n\nSee [`Go Project Layout`](https:\u002F\u002Fmedium.com\u002Fgolang-learn\u002Fgo-project-layout-e5213cdcfaa2) for additional background information.\n\nMore about naming and organizing packages as well as other code structure recommendations:\n* [GopherCon EU 2018: Peter Bourgon - Best Practices for Industrial Programming](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=PTE4VJIdHPg)\n* [GopherCon Russia 2018: Ashley McNamara + Brian Ketelsen - Go best practices.](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=MzTcsI6tn-0)\n* [GopherCon 2017: Edward Muller - Go Anti-Patterns](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=ltqV6pDKZD8)\n* [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=oL6JBUk6tj0)\n\nA Chinese post about Package-Oriented-Design guidelines and Architecture layer\n* [面向包的设计和架构分层](https:\u002F\u002Fgithub.com\u002Fdanceyoung\u002Fpaper-code\u002Fblob\u002Fmaster\u002Fpackage-oriented-design\u002Fpackageorienteddesign.md)\n\nHere is a popular open source project that strictly follows the project-layout's project specification for your reference: [iam](https:\u002F\u002Fgithub.com\u002Fmarmotedu\u002Fiam).\n\n## Go Directories\n\n### `\u002Fcmd`\n\nMain applications for this project.\n\nThe directory name for each application should match the name of the executable you want to have (e.g., `\u002Fcmd\u002Fmyapp`).\n\nDon't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the `\u002Fpkg` directory. If the code is not reusable or if you don't want others to reuse it, put that code in the `\u002Finternal` directory. You'll be surprised what others will do, so be explicit about your intentions!\n\nIt's common to have a small `main` function that imports and invokes the code from the `\u002Finternal` and `\u002Fpkg` directories and nothing else.\n\nSee the [`\u002Fcmd`](cmd\u002FREADME.md) directory for examples.\n\n### `\u002Finternal`\n\nPrivate application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 [`release notes`](https:\u002F\u002Fgolang.org\u002Fdoc\u002Fgo1.4#internalpackages) for more details. Note that you are not limited to the top level `internal` directory. You can have more than one `internal` directory at any level of your project tree.\n\nYou can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the `\u002Finternal\u002Fapp` directory (e.g., `\u002Finternal\u002Fapp\u002Fmyapp`) and the code shared by those apps in the `\u002Finternal\u002Fpkg` directory (e.g., `\u002Finternal\u002Fpkg\u002Fmyprivlib`).\n\nYou use internal directories to make packages private. If you put a package inside an internal directory, then other packages can’t import it unless they share a common ancestor. And it’s the only directory named in Go’s documentation and has special compiler treatment.\n\n### `\u002Fpkg`\n\nLibrary code that's ok to use by external applications (e.g., `\u002Fpkg\u002Fmypubliclib`). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the `internal` directory is a better way to ensure your private packages are not importable because it's enforced by Go. The `\u002Fpkg` directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The [`I'll take pkg over internal`](https:\u002F\u002Ftravisjeffery.com\u002Fill-take-pkg-over-internal\u002F) blog post by Travis Jeffery provides a good overview of the `pkg` and `internal` directories and when it might make sense to use them.\n\nIt's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: [`Best Practices for Industrial Programming`](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=oL6JBUk6tj0) and [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=3gQa1LWwuzk)).\n\nSee the [`\u002Fpkg`](pkg\u002FREADME.md) directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it.\n\nIt's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components).\n\nThe `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the pattern (see [`this`](https:\u002F\u002Ftwitter.com\u002Fbradfitz\u002Fstatus\u002F1039512487538970624) Brad Fitzpatrick's tweet for more context).\n\n### `\u002Fvendor`\n\nApplication dependencies (managed manually or by your favorite dependency management tool like the new built-in [`Go Modules`](https:\u002F\u002Fgo.dev\u002Fwiki\u002FModules) feature). The `go mod vendor` command will create the `\u002Fvendor` directory for you. Note that you might need to add the `-mod=vendor` flag to your `go build` command if you are not using Go 1.14 where it's on by default.\n\nDon't commit your application dependencies if you are building a library.\n\nNote that since [`1.13`](https:\u002F\u002Fgolang.org\u002Fdoc\u002Fgo1.13#modules) Go also enabled the module proxy feature (using [`https:\u002F\u002Fproxy.golang.org`](https:\u002F\u002Fproxy.golang.org) as their module proxy server by default). Read more about it [`here`](https:\u002F\u002Fblog.golang.org\u002Fmodule-mirror-launch) to see if it fits all of your requirements and constraints. If it does, then you won't need the `vendor` directory at all.\n\n## Service Application Directories\n\n### `\u002Fapi`\n\nOpenAPI\u002FSwagger specs, JSON schema files, protocol definition files.\n\nSee the [`\u002Fapi`](api\u002FREADME.md) directory for examples.\n\n## Web Application Directories\n\n### `\u002Fweb`\n\nWeb application specific components: static web assets, server side templates and SPAs.\n\n## Common Application Directories\n\n### `\u002Fconfigs`\n\nConfiguration file templates or default configs.\n\nPut your `confd` or `consul-template` template files here.\n\n### `\u002Finit`\n\nSystem init (systemd, upstart, sysv) and process manager\u002Fsupervisor (runit, supervisord) configs.\n\n### `\u002Fscripts`\n\nScripts to perform various build, install, analysis, etc operations.\n\nThese scripts keep the root level Makefile small and simple (e.g., [`https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fterraform\u002Fblob\u002Fmain\u002FMakefile`](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fterraform\u002Fblob\u002Fmain\u002FMakefile)).\n\nSee the [`\u002Fscripts`](scripts\u002FREADME.md) directory for examples.\n\n### `\u002Fbuild`\n\nPackaging and Continuous Integration.\n\nPut your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the `\u002Fbuild\u002Fpackage` directory.\n\nPut your CI (travis, circle, drone) configurations and scripts in the `\u002Fbuild\u002Fci` directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the `\u002Fbuild\u002Fci` directory linking them to the location where the CI tools expect them (when possible).\n\n### `\u002Fdeployments`\n\nIaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes\u002Fhelm, terraform). Note that in some repos (especially apps deployed with kubernetes) this directory is called `\u002Fdeploy`.\n\n### `\u002Ftest`\n\nAdditional external test apps and test data. Feel free to structure the `\u002Ftest` directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have `\u002Ftest\u002Fdata` or `\u002Ftest\u002Ftestdata` if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with \".\" or \"_\", so you have more flexibility in terms of how you name your test data directory.\n\nSee the [`\u002Ftest`](test\u002FREADME.md) directory for examples.\n\n## Other Directories\n\n### `\u002Fdocs`\n\nDesign and user documents (in addition to your godoc generated documentation).\n\nSee the [`\u002Fdocs`](docs\u002FREADME.md) directory for examples.\n\n### `\u002Ftools`\n\nSupporting tools for this project. Note that these tools can import code from the `\u002Fpkg` and `\u002Finternal` directories.\n\nSee the [`\u002Ftools`](tools\u002FREADME.md) directory for examples.\n\n### `\u002Fexamples`\n\nExamples for your applications and\u002For public libraries.\n\nSee the [`\u002Fexamples`](examples\u002FREADME.md) directory for examples.\n\n### `\u002Fthird_party`\n\nExternal helper tools, forked code and other 3rd party utilities (e.g., Swagger UI).\n\n### `\u002Fgithooks`\n\nGit hooks.\n\n### `\u002Fassets`\n\nOther assets to go along with your repository (images, logos, etc).\n\n### `\u002Fwebsite`\n\nThis is the place to put your project's website data if you are not using GitHub pages.\n\nSee the [`\u002Fwebsite`](website\u002FREADME.md) directory for examples.\n\n## Directories You Shouldn't Have\n\n### `\u002Fsrc`\n\nSome Go projects do have a `src` folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-)\n\nDon't confuse the project level `\u002Fsrc` directory with the `\u002Fsrc` directory Go uses for its workspaces as described in [`How to Write Go Code`](https:\u002F\u002Fgolang.org\u002Fdoc\u002Fcode.html). The `$GOPATH` environment variable points to your (current) workspace (by default it points to `$HOME\u002Fgo` on non-windows systems). This workspace includes the top level `\u002Fpkg`, `\u002Fbin` and `\u002Fsrc` directories. Your actual project ends up being a sub-directory under `\u002Fsrc`, so if you have the `\u002Fsrc` directory in your project the project path will look like this: `\u002Fsome\u002Fpath\u002Fto\u002Fworkspace\u002Fsrc\u002Fyour_project\u002Fsrc\u002Fyour_code.go`. Note that with Go 1.11 it's possible to have your project outside of your `GOPATH`, but it still doesn't mean it's a good idea to use this layout pattern.\n\n\n## Badges\n\n* [Go Report Card](https:\u002F\u002Fgoreportcard.com\u002F) - It will scan your code with `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` and `misspell`. Replace `github.com\u002Fgolang-standards\u002Fproject-layout` with your project reference.\n\n    [![Go Report Card](https:\u002F\u002Fgoreportcard.com\u002Fbadge\u002Fgithub.com\u002Fgolang-standards\u002Fproject-layout?style=flat-square)](https:\u002F\u002Fgoreportcard.com\u002Freport\u002Fgithub.com\u002Fgolang-standards\u002Fproject-layout)\n\n* ~~[GoDoc](http:\u002F\u002Fgodoc.org) - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.~~\n\n    [![Go Doc](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fgodoc-reference-blue.svg?style=flat-square)](http:\u002F\u002Fgodoc.org\u002Fgithub.com\u002Fgolang-standards\u002Fproject-layout)\n\n* [Pkg.go.dev](https:\u002F\u002Fpkg.go.dev) - Pkg.go.dev is a new destination for Go discovery & docs. You can create a badge using the [badge generation tool](https:\u002F\u002Fpkg.go.dev\u002Fbadge).\n\n    [![PkgGoDev](https:\u002F\u002Fpkg.go.dev\u002Fbadge\u002Fgithub.com\u002Fgolang-standards\u002Fproject-layout)](https:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002Fgolang-standards\u002Fproject-layout)\n\n* Release - It will show the latest release number for your project. Change the github link to point to your project.\n\n    [![Release](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Frelease\u002Fgolang-standards\u002Fproject-layout.svg?style=flat-square)](https:\u002F\u002Fgithub.com\u002Fgolang-standards\u002Fproject-layout\u002Freleases\u002Flatest)\n\n## Notes\n\nA more opinionated project template with sample\u002Freusable configs, scripts and code is a WIP.\n","该项目提供了一种标准的Go语言项目布局。它定义了包括`internal`、`cmd`等在内的目录结构，以及一些常见的支持性目录，适用于大多数实际应用中的Go项目。该布局强调了代码组织的重要性，帮助开发者避免随着项目规模增长而出现的依赖混乱和全局状态管理问题。特别适合于团队协作开发或是开源项目中使用，能够有效提高代码的可维护性和模块化程度。需要注意的是，对于初学者或小型个人项目来说，这种布局可能过于复杂，建议从更简单的结构开始。",2,"2026-06-11 02:37:44","top_all"]