Golang项目目录结构如何组织_Golang项目结构教程【核心】-Golang-PHP中文网

main.go 应放在 cmd/ 子目录下（如 cmd/myapp/main.go），根目录仅保留 go.mod 等元信息；internal/ 是 Go 强制的访问边界，用于封装不对外承诺的实现；API 层负责错误映射为 HTTP 状态码，domain 层只定义业务语义错误；go.mod 的 module 名应为最终导入路径（如 github.com/user/repo）。

golang项目目录结构如何组织_golang项目结构教程【核心】

main.go 放哪？别放根目录

Go 项目启动入口 main.go 必须在 main 包里，但不意味着它该躺在项目最外层。根目录堆 main.go + 几个 .go 文件，很快就会变成“不知道谁依赖谁”的泥潭。

实操建议：

为每个可执行程序单独建子目录，比如 cmd/myapp/，里面放 main.go 和它的直接依赖（如 CLI 参数解析）
cmd/ 下可并列多个命令，例如 cmd/myapp/ 和 cmd/myapp-worker/，对应不同二进制产出
根目录只保留 go.mod、README.md、.gitignore 等元信息，不放业务逻辑

internal/ 不是摆设，是包可见性的安全线

Go 没有 private 包关键字，internal/ 是唯一被 Go 工具链强制约束的访问边界：只有父目录及祖先目录下的包能 import internal/xxx。很多人把它当普通文件夹用，结果外部模块意外依赖了本该封闭的实现细节。

常见错误现象：

第三方库尝试 import "myproject/internal/handler" 报错 use of internal package not allowed
测试文件放在 internal/ 外却想测内部函数，只能暴露不该导出的标识符

实操建议：

把真正不对外承诺的实现（如数据库连接池封装、中间件内部状态管理）全塞进 internal/
pkg/ 用于放**稳定、有明确接口、允许外部依赖**的公共能力，比如通用校验器 pkg/validator
别为了省事把 internal/ 建成 internal/common 或 internal/utils —— 这类命名往往意味着职责模糊、越界风险高

API 层和 domain 层怎么分？从 error 类型开始切

很多 Go 项目一上来就分 handler、service、repository，但没想清楚分层依据。最实际的切入点是错误处理：HTTP handler 需要返回 400 Bad Request，domain 层只该关心“库存不足”这种业务语义，不该知道 HTTP 状态码。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

使用场景：

API 层（api/ 或 handler/）负责把 error 映射成 HTTP 状态码和 JSON 错误体，比如识别 ErrInsufficientStock → 400
domain 层（domain/）只定义业务错误，用自定义 error 类型或哨兵值，如 var ErrInsufficientStock = errors.New("insufficient stock")
别在 domain 层 import net/http 或任何框架相关包；也别让 handler 直接调用数据库驱动方法

go.mod 的 module 名不是项目名，是导入路径前缀

go mod init myproject 生成的 module myproject 很容易误导人——它不是项目代号，而是所有 import 语句的根路径。一旦写死，后续迁移到组织仓库（如 github.com/org/myproject）就得改满屏 import，且 go get 会失败。

性能 / 兼容性影响：