Go 项目常见的目录结构是怎样的？

Go 社区事实标准参考 golang-standards/project-layout：cmd/ 放应用入口（每个可执行文件一个子目录，如 cmd/server/main.go）；internal/ 放私有代码，编译器强制禁止外部模块导入；pkg/ 放可被外部引用的库代码（争议较大，很多项目不用）；api/ 放 OpenAPI、proto 定义；configs/ 配置模板；scripts/ 构建脚本；test/ 或 e2e/ 放集成测试。

更重要的是内部划分原则：按业务领域分包而不是按技术分层（user/order 而不是 controller/service/dao 的 Java 式分层）；包名应表达用途而非泛泛的 util/common；依赖方向从外向内，领域核心不依赖框架细节。小项目不需要一开始就铺满目录，扁平结构加 internal 足够，结构应随复杂度演进。

cmd/server/main.go
internal/user/{service.go,repo.go}
internal/order/
api/openapi.yaml
go.mod

易错点：util 包是反模式，会把无关代码耦合在一起；循环导入是包划分不合理的信号；internal 的可见性规则以包含 internal 的目录的父级为边界。追问方向：go work 多模块管理、monorepo 下的模块划分、DDD 分层在 Go 中的落地。