按业务领域划分子包并结合三层架构是Go项目推荐的分层方式。1. 以user、order等业务模块为单位组织子包，每个包内包含handler、service、repository和model，实现职责分明；2. 使用internal目录保护内部代码不被外部引用；3. service层依赖接口而非具体实现，通过依赖倒置提升可测试性；4. 工具类统一放于pkg/util、pkg/log等共享包，避免重复与循环引用。结构应随项目演进而调整，保持低耦合、高内聚。
在Go项目中，随着业务复杂度上升，把所有代码放在一个包里会变得难以维护。合理的分层和拆分子包能让项目结构更清晰、职责更分明，也便于团队协作和单元测试。以下是Golang中常见的业务逻辑拆分与package分层实践。
按业务领域划分子包（推荐）
将功能按业务领域（Domain）组织，是Go项目中最自然、最可维护的方式。每个子包代表一个明确的业务模块，比如用户管理、订单处理、支付服务等。
例如：
- user/：处理用户注册、登录、信息更新
- order/：处理订单创建、查询、状态变更
- payment/：处理支付流程、回调、对账
- product/：商品信息管理
这种结构让新成员能快速定位代码，也方便独立测试和复用。每个包内可以有自己的model、service、repository等，但对外只暴露必要的接口和方法。
立即学习“go语言免费学习笔记（深入）”；
常见分层模式：三层架构 + 子包
虽然Go不强制MVC或分层，但在中大型项目中，结合分层与子包能提升结构清晰度。典型分层包括：
- handler/ 或 api/：接收HTTP请求，做参数校验、调用service，返回响应
- service/：核心业务逻辑，协调多个repository或外部服务
- repository/ 或 dao/：数据访问层，对接数据库或缓存
- model/：数据结构定义，如struct和数据库映射
这些层可以按业务分布在不同子包中，比如：
project/ ├── user/ │ ├── handler.go │ ├── service.go │ ├── repository.go │ └── model.go ├── order/ │ ├── handler.go │ ├── service.go │ └── model.go ├── internal/ │ └── middleware/ └── main.go
使用 internal 目录保护内部包，防止被外部项目导入。
接口与依赖倒置：降低耦合
为了提高可测试性和灵活性，建议在service层依赖抽象而非具体实现。例如，在user/service.go中不要直接调用具体的repository结构体，而是依赖一个定义在当前包的接口：
type UserRepository interface {
FindByID(id int) (*User, error)
Update(u *User) error
}
然后由main函数或初始化逻辑注入具体实现。这样repository的变更不会影响service，也便于写mock测试。
工具与共享代码的处理
通用工具类应放在独立包中，避免重复：
- pkg/util：通用辅助函数，如时间处理、字符串格式化
- pkg/log：封装日志库，统一调用方式
- middleware/：HTTP中间件，如鉴权、日志记录
注意不要让业务包反过来依赖工具包形成循环引用。保持依赖方向清晰：业务 → 工具，高层 → 低层。
基本上就这些。关键不是套模板，而是根据项目规模和团队习惯逐步演进结构。小项目可以从平铺开始，功能多了再拆。只要保持单一职责、低耦合、高内聚，Go的包机制足够灵活支撑良好设计。
