Standard Go Project Layout
Go 社区广泛参考的项目目录结构模板,整理了 cmd、internal、pkg、api、configs 等常见目录约定,帮助中大型 Go 项目建立清晰、可维护的代码组织方式。
爱鲜报评分
0.0
0 人评分
57k
星数
是
中文
Makefile
主语言
是
活跃
89
贡献者
人工分析
EDITORIAL推荐理由
这是 Go 生态中星标最高的项目结构参考之一,虽非官方标准,但已成为大量开源项目的实际约定。它不是可直接运行的框架,而是一份可裁剪的目录模板与说明文档,适合团队在项目启动阶段对齐结构。建议按需取用,不要盲目全盘照搬。
适用场景
- 中大型 Go 后端服务项目初始化
- 团队统一代码目录规范
- 开源 Go 库/工具的项目骨架设计
- Go 项目代码评审与结构重构参考
优点
- 社区认可度高,参考案例丰富
- 目录职责说明清晰,便于团队沟通
- 支持按需裁剪,不强绑定具体框架
- 提供简体中文等多语言翻译文档
缺点
- 并非 Go 官方标准,存在争议
- 对小型项目或练手项目明显过重
- 不涉及 Clean Architecture 等分层细节
- 直接克隆会引入大量空目录与冗余文件
上手难度
入门
项目简介
Standard Go Project Layout 是 Go 社区中流传最广的项目目录结构参考模板。它汇总了 Go 生态里常见的历史与新兴目录约定,并给出每个目录的职责说明,帮助开发者在项目变大、协作人数变多时保持代码结构清晰。
需要强调:它不是 Go 官方核心团队定义的标准,而是一份社区共识性质的布局参考。官方关于模块组织的建议可参考 Go 文档中的 Organizing a Go module。
核心目录约定
应用与私有代码
/cmd:各可执行程序的入口,目录名通常与生成的二进制名一致,例如/cmd/myapp。这里只放少量main函数代码,真正的逻辑应下沉到internal或pkg。/internal:私有代码,Go 编译器会强制限制外部模块导入,是保护内部实现的可靠方式。可在任意层级设置多个internal目录。/pkg:允许被外部项目导入的公共库代码。放入前需谨慎,因为一旦公开就意味着要维护兼容性。
常见支撑目录
/api:OpenAPI、Protobuf 等接口定义/configs:配置模板与默认配置/deployments或/deploy:容器与编排部署描述/test:额外的测试数据与集成测试辅助/scripts:构建、安装、分析等脚本/docs:设计文档与用户文档/web、/assets:Web 静态资源与前端资产
使用方式
该仓库本身是一个模板,推荐做法是按需取用:
- 克隆或浏览仓库,理解各目录职责;
- 只保留当前项目真正需要的目录;
- 删除其余空目录与示例文件;
- 结合团队规范补充 README 与 CI 配置。
一个最小可用的 Go 项目其实只需要:
myapp/
├── go.mod
└── main.go
当项目增长、出现多人协作或需要对外提供库时,再逐步引入 cmd、internal、pkg 等结构。
适用与不适用
适合:中大型服务、需要长期维护的开源项目、多人协作的团队项目。
不适合:学习 Go 的练手项目、概念验证(PoC)、个人小工具。这类场景从单个 main.go 加 go.mod 起步更高效。
补充建议
- 命名与格式优先使用
gofmt与staticcheck,golint已废弃。 - 项目结构应服务于可读性与依赖管理,而非为了“看起来规范”堆砌目录。
- 仓库提供简体中文、繁体中文、日文、韩文等多语言 README,中文开发者可直接阅读中文版。
评论
- 暂无评论,来写第一条吧。