合理的Go项目目录结构提升可维护性与协作效率。1. 遵循社区惯例：根目录放go.mod，/cmd/存main包，/pkg/放可复用库，/internal/存私有代码，/api/或/proto/存接口定义，/configs/存配置，/docs/存文档，/scripts/存脚本。2. 按业务功能划分：如/user/、/order/等模块内含各自handler、service、repository和model，代码集中，职责清晰。3. 正确使用/internal/与/pkg/：前者限制外部导入，保护核心逻辑；后者提供稳定公共库，避免过早暴露未成熟代码。4. 接口与实现分离：在服务层定义接口，实现隐藏于结构体，便于mock测试，符合依赖倒置原则。结构需随项目演进持续优化，保持一致性和低认知成本。
Go语言的包组织结构直接影响项目的可维护性与团队协作效率。合理的目录结构能让代码职责清晰、依赖明确，也便于后期扩展。下面介绍几种常见的Golang项目目录设计原则和推荐结构。
1. 遵循Go社区通用约定
Go项目不强制要求特定的目录结构，但社区逐渐形成了一些被广泛接受的惯例。使用这些惯例可以提升项目的可读性和兼容性。
- 根目录放主模块声明（go.mod）：包含模块名、Go版本及依赖项。
- /cmd/：存放可执行程序的main包，每个子目录对应一个独立命令。
- /pkg/：存放可被外部项目复用的公共库代码。
- /internal/：私有代码，仅当前项目可用，Go会限制外部导入。
- /api/ 或 /proto/：存放API定义，如OpenAPI规范或Protobuf文件。
- /configs/：配置文件，例如YAML、JSON或环境变量说明。
- /docs/：项目文档，包括设计说明、接口文档等。
- /scripts/：自动化脚本，如部署、构建、数据库迁移等。
2. 按功能划分而非层划分
传统分层架构常分为handler、service、dao等目录，所有模块共用同一层。这种方式在小型项目中可行，但随着业务增长，跨模块调用容易混乱。
更推荐按业务功能模块组织代码，每个模块内部自包含各层逻辑：
立即学习“go语言免费学习笔记（深入）”；
/example-project/
├── cmd/
│ └── app/
│ └── main.go
├── internal/
│ ├── user/
│ │ ├── handler/
│ │ ├── service/
│ │ ├── repository/
│ │ └── model/
│ └── order/
│ ├── handler/
│ ├── service/
│ ├── repository/
│ └── model/
└── pkg/
└── util/
└── logger.go
这种结构让新增或修改某个功能时，相关代码集中在一个目录下，降低理解成本。
3. 合理使用internal与pkg控制可见性
Go通过目录路径控制包的可见性。掌握这两者用途有助于设计清晰的边界：
- /internal/ 下的包只能被本项目导入，适合存放核心业务逻辑。
- /pkg/ 中的包设计为可导出，供其他项目使用，应保持稳定、解耦。
避免将未成熟的内部逻辑放入/pkg/，防止外部项目依赖后难以重构。
4. 接口与实现分离，利于测试与扩展
在服务层或仓库层定义接口，具体实现放在同包或子包中。这样可以在测试时轻松替换为mock对象。
例如：
/internal/user/service.go
package user
type UserService interface {
GetUser(id int) (*User, error)
}
type userService struct { ... }
func NewUserService(repo UserRepository) UserService { ... }
接口定义在上层，实现细节隐藏，符合依赖倒置原则。
基本上就这些。好的目录结构不是一成不变的，应随项目演进持续优化。关键是保持一致性、职责分明，并让新成员能快速定位代码。不复杂但容易忽略。
