The answer is: Go applications do not have a mandatory project layout, but the community generally adopts a standard structure to improve maintainability and scalability. 1. cmd/ stores the program entrance, and each subdirectory corresponds to an executable file, such as cmd/myapp/main.go; 2. internal/ stores private code, cannot be imported by external modules, and is used to encapsulate business logic and services; 3. pkg/ stores publicly reusable libraries for importing other projects; 4. API/ is optional, and stores API definition files such as OpenAPI and Protobuf; 5. config/, scripts/, and web/ store configuration files, scripts and web resources respectively; 6. The root directory contains go.mod and go.sum management dependencies, as well as project metafiles such as README.md and Makefiles. This structure is suitable for medium and large projects or multi-command applications, and small tools can start with simple structures and evolve with requirements. This layout is widely adopted by Uber, Kubernetes, etc. The core principle is to clearly separate the focus, protect internal code, support reuse, and ultimately realize the maintainability and sustainable expansion of the code.

There isn't one single enforced project layout for Go applications—Go itself doesn't require a specific directory structure. However, the community has converged on a de facto standard that promotes clarity, scalability, and tool compatibility, especially as your project grows beyond a simple command-line tool.

Here's a widely accepted and practical layout for a typical Go application:

 myapp/
├── cmd/
│ └── myapp/
│ └── main.go
├── internal/
│ ├── service/
│ └── processor.go
│ └── util/
│ └── helpers.go
├── pkg/
│ └── publicapi/
│ └── client.go
├── pkg/
├── internal/
├── cmd/
├── api/
│ └── openapi.yaml
├── config/
│ └── config.yaml
├── scripts/
│ └── deploy.sh
├── web/
│ ├── static/
│ └── templates/
├── go.mod
├── go.sum
├── README.md
└── Makefile

Let's break down the key directories and their purpose:

1. cmd/ – Entry points for your application

Each subdirectory under cmd/ represents a separate executable.
For example:

• cmd/myapp/main.go → builds the myapp binary
• cmd/myadmin/main.go → builds an admin tool

Each main.go should be minimal—just enough to wire up dependencies and start the app.

2. internal/ – Private application logic

Code here is not important by external modules (thanks to Go's internal package rule). Use this for:

• Business logic
• Application services
• Utilities not meant for reuse outside

Structure it by domain or layer:

 Internal/
├── auth/
├── user/
├── database/
└── middleware/

3. pkg/ – Public libraries for external use

If parts of your code are meant to be imported by other projects, put them here.
For example:

• API clients
• Shared utilities
• Reusable components

Keep in mind: only put code here if you intend it to be stable and publicly supported.

4. api/ – API definitions (optional)

Store OpenAPI/Swagger specs, protobuf files, or GraphQL schemas here. Useful for documenting and generating client/server code.

5. config/ , scripts/ , web/ , etc.

These are self-explanatory but commonly used:

• config/ – Configuration files (YAML, JSON, etc.)
• scripts/ – Deployment, setup, or automation scripts
• web/ – Static assets or templates (if building a web app)

6. go.mod and go.sum

These should be in the root. They define your module and its dependencies.

 module github.com/yourname/myapp
go 1.21

When to use this layout?

• ? You're building a medium to large application
• ? You have multiple binaries ( cmd/ )
• ? You want to separate internal vs. public code
• ? You plan to reuse components or expose libraries

For small tools or simple services , this might be overkill. A flat structure with just main.go and go.mod is totally fine initially.

Popular references

While not officially mandated, this layout aligns with guidance from:

• Uber's Go Style Guide
• Go Pro Tips
• Real-world projects like Kubernetes, Terraform, and Grafana

In short: start simple, evolve towards this structure as your app grows . The key ideas—separating cmd , protecting internal , and organizing by concern—are what matter most.

Basically, keep it clean, logical, and scalable.

The above is the detailed content of What is the standard project layout for a Go application?. For more information, please follow other related articles on the PHP Chinese website!