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 反而增加认知负担。但只要出现以下任一情况，目录结构就必须明确：
- 需要构建多个命令（如
myctlCLI 和myserver后台服务） - 别人要
go get github.com/you/mylib并调用你的函数 - 团队里有人开始 copy-paste
internal/utils.go到另一个项目
这时候模糊地带最危险：比如把核心算法放 pkg，但它的配置解析器却藏在 cmd 里——外部用户能 import 算法，却没法正确初始化它。这种割裂比没分层还难修。
