17370845950

Go项目推荐采用cmd/、internal/、pkg/、api/、configs/、scripts/等目录结构，按业务域组织包，配置与代码分离，测试文件与源码同目录，构建用Makefile统一管理。

Go 项目目录结构没有官方强制规范，但社区已形成成熟、可扩展的实践模式。关键在于按职责分离、避免循环依赖、便于测试和部署。

核心目录划分（推荐基础结构）

一个清晰的 Go 项目通常包含以下顶层目录：

• cmd/：存放可执行程序入口（main.go），每个子目录对应一个二进制文件（如 cmd/myapp、cmd/myworker）
• internal/：仅限本项目使用的私有包，外部无法 import（Go 1.4+ 强制保护）
• pkg/：可被其他项目复用的公共包（导出接口稳定、有文档、带单元测试）
• api/ 或 proto/：API 定义（OpenAPI spec）、gRPC proto 文件及生成代码
• configs/：配置文件模板与默认值（如 configs/config.yaml、configs/config.local.yaml.example）
• scripts/：部署、生成、检查等辅助脚本（bash / make / golangci-lint 配置）
• go.mod 和 go.sum：根目录下初始化模块（go mod init example.com/myapp）

包组织原则：小而专注，按领域而非技术分层

避免按 controller/service/repository 这类 Java 风格分层。Go 更倾向按业务域或功能边界组织包：

• 用户相关逻辑 → internal/user（含 user.User 结构、注册/登录逻辑、密码加密等）
• 订单处理 → internal/order（含 Order 结构、状态机、支付回调处理器）
• 共享工具 → pkg/util（非业务通用函数，如时间格式化、JSON 辅助、错误包装）
• 数据库访问 → internal/storage 或 internal/repo（封装 SQL / ORM 调用，不暴露 driver 细节）

每个包应有明确职责，go list ./... 应能直观反映依赖关系；内部包之间通过接口解耦（如 order.Service 依赖 user.Repository 接口，而非具体实现）。

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

配置管理：代码与配置分离，环境感知加载

不硬编码配置，也不把 config struct 放在 main 包里。推荐做法：

• 定义配置结构体在 configs/config.go，使用 struct tag 标注 yaml/json key
• 用 github.com/spf13/viper 或原生 gopkg.in/yaml.v3 + os.ReadFile 加载
• 支持多环境：优先读取 config.$ENV.yaml（如 config.prod.yaml），再 fallback 到 config.yaml
• 敏感字段（如 DB password）通过环境变量注入，配置文件中留空或占位（password: ${DB_PASSWORD}）

测试与构建：保持就近与可运行性

测试文件与源码同目录（user.go 与 user_test.go 并列），测试包名加 _test 后缀仅当需跨包测试时使用。

• 单元测试覆盖核心逻辑，用 testify/assert 或原生 testing 即可
• 集成测试放在 internal/integration/，启动真实依赖（如 SQLite 内存 DB、mock HTTP server）
• 构建脚本写在 Makefile 中：make build（编译所有 cmd）、make test（运行全部测试）、make lint（golangci-lint）

不复杂但容易忽略