Golang项目标准目录布局_cmd、pkg、internal文件夹作用

cmd目录仅存放main入口，每个子目录对应独立二进制；业务逻辑须下沉至pkg（对外API）或internal（私有实现），禁止cmd直接import业务包、共享全局状态或写测试。

cmd 文件夹只放 main 入口，不放业务逻辑

go 项目里 cmd 的唯一职责是定义可执行命令的入口点，每个子目录对应一个独立二进制（比如 cmd/myapp、cmd/myapp-worker）。它必须干净——不能 import 本项目的 pkg 或 internal 以外的业务包，更不能把服务启动、配置解析、路由注册这些逻辑塞进去。

常见错误是把 main.go 写成“大杂烩”：读配置、连 DB、初始化中间件、启动 http server 全堆在里头。这样会导致无法单元测试、复用困难、多命令间耦合严重。

• 所有初始化逻辑应下沉到 pkg 或 internal 中的函数，main() 只负责调用它们
• 不同命令之间禁止共享变量或全局状态；靠参数和返回值通信
• cmd 下不写测试文件（*_test.go），测试全放在对应逻辑所在的包里

pkg 是给外部用的公共 API，internal 是项目私有实现

pkg 目录里的包要能被其他项目 go get 引用，所以它必须稳定、有文档、有明确契约；而 internal 是 Go 编译器强制限制“仅本模块可用”的地方——任何外部 module 都无法 import your-module/internal/xxx，哪怕路径对也不行。

容易踩的坑是把还没定型的工具函数、带副作用的 client 初始化、或者强依赖本项目配置结构体的代码，误放进 pkg。结果就是别人一引用就 break，或者你改个字段名就得发 v2。

立即学习“go语言免费学习笔记（深入）”；

• pkg 里只暴露接口（type Service Interface{...}）和构造函数（func NewService(...)），不暴露 Struct 字段
• internal 可以自由组织：按层（internal/handler、internal/repo）、按功能（internal/auth、internal/metrics），但禁止反向依赖 cmd
• 如果某个包暂时没想好是否开放，先放 internal；等 API 稳定、有真实外部使用者了，再挪到 pkg

go mod tidy 不会自动创建或识别这些目录

Go 模块系统完全不关心 cmd、pkg、internal 这些目录名，它们只是社区约定。这意味着：go mod tidy 不会因为你新建了 cmd/foo 就帮你拉依赖，也不会因为删了 internal/bar 就警告你破坏了封装。

真正起作用的是 Go 编译器对 internal 的硬性检查，以及你手动维护的 import 路径。很多人以为只要目录名对，Go 就“懂”分层，结果在 cmd 里直接 import internal/xxx，又在别的 module 里尝试 import 同样的路径，然后收到 use of internal package not allowed 错误才反应过来。

• go list -f '{{.ImportPath}}' ./... 可快速查看当前模块下所有可被 import 的包路径，确认 internal 是否意外暴露
• CI 中建议加一条检查：禁止 cmd/** 出现 import ".../internal/..."（虽然合法，但违背分层意图）
• ide（如 VS Code + gopls）不会自动补全 internal 下的包给外部项目，这是好事，别试图绕过

小项目不用硬套，但一旦有多个二进制或对外提供 SDK 就得立刻分清

单个 main.go 加几个 .go 文件的小工具，硬拆 cmd/pkg/internal 反而增加认知负担。但只要出现以下任一情况，目录结构就必须明确：

• 需要构建多个命令（如 myctl CLI 和 myserver 后台服务）
• 别人要 go get github.com/you/mylib 并调用你的函数
• 团队里有人开始 copy-paste internal/utils.go 到另一个项目

这时候模糊地带最危险：比如把核心算法放 pkg，但它的配置解析器却藏在 cmd 里——外部用户能 import 算法，却没法正确初始化它。这种割裂比没分层还难修。