golang如何实现分层架构设计_golang分层架构设计实现实战-Golang-PHP中文网

Go项目需立即划清handler/service/repo边界，否则代码迅速沦为混杂SQL、API调用等的大杂烩；分层使各层仅依赖下层接口，便于替换数据库、加缓存等，且通过三层独立struct（UserRequest/User/UserModel）隔离数据模型，提升可维护性与安全性。

golang如何实现分层架构设计_golang分层架构设计实现实战

为什么 Go 项目一上来就该划清 handler / service / repo 边界

因为 Go 没有强制的框架约束，不手动隔离职责，两周后代码就会变成 handler 里拼 SQL、调第三方 API、写日志、做参数校验的大杂烩。这不是风格问题，是维护成本爆炸的起点。

分层不是为了“看起来规范”，而是让每个包只依赖更底层的接口（而非具体实现），后续替换数据库、加缓存、切 RPC 协议时，只需重写 repo 或 service 的实现，handler 完全不动。

handler 层只处理 HTTP 生命周期：解析请求、校验结构体（用 validator）、调 service 方法、封装响应
service 层专注业务逻辑：事务控制、领域规则判断、组合多个 repo 调用；它不能直接 import database/sql 或 http.Client
repo 层只干一件事：把 service 给的 domain model 映射成 SQL/Redis/ES 操作；返回的也必须是 domain struct，不能暴露 *sql.Rows 或 redis.Cmdable

如何定义跨层传递的数据结构：别用 database struct 做 API 返回

常见错误是把 UserModel（带 CreatedAt、UpdatedAt、ID 等字段）直接从 repo 透传到 HTTP 响应。这会导致：前端拿到敏感字段、数据库改表结构时所有上层都得改、无法对不同端（App/Web/API）做字段裁剪。

正确做法是三层各用各自的 struct：

handler 用 UserRequest 接参，UserResponse 返回（字段名可与前端约定一致，比如 user_id）
service 用 User（纯业务字段，无 DB 元信息，如 Balance float64）
repo 用 UserModel（含 ID, CreatedAt, DeletedAt 等 ORM 所需字段）

转换不要手写，用 mapstructure 或轻量级工具（如 copier），但注意：只在层边界做一次转换，别在 service 里又转一遍 User → UserModel。

repo 层怎么写才真正可测试、可替换

关键不是“用了 interface”，而是 interface 是否只描述“我要做什么”，而不是“DB 怎么做”。比如这个定义就错了：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

type UserRepository interface {
    GetByID(id int) (*UserModel, error)
    Update(u *UserModel) error
}

它绑死了主键类型（int）和更新方式（全量）。换成：

type UserRepository interface {
    FindOne(ctx context.Context, filter map[string]interface{}) (*User, error)
    Save(ctx context.Context, u *User) error
}

好处是：filter 可以是 map[string]interface{"id": "u_123"}（适配 MongoDB），也可以是 map[string]interface{"email": "a@b.com"}（用于登录查用户），Save 也不限定是 INSERT 还是 UPSERT。

测试时用内存 map 实现 UserRepository，完全绕过数据库
上线后想切 TiDB？只要新写一个 TiDBUserRepo 实现同一接口即可
千万别在 interface 里塞 BeginTx()、Exec() 这类 DB 特定方法

service 层事务和错误处理的实操陷阱

Go 里事务不是靠“自动回滚”，而是靠显式控制 tx.Commit() / tx.Rollback()。常见错误是：在 service 方法里开了事务，但某个 repo 调用失败后没 return，继续往下走，最后 commit 了部分成功操作。

事务必须由 service 方法顶层开启，传入各 repo 方法（通过 context.WithValue 或参数传递 *sql.Tx）
错误要分类：领域错误（如 ErrInsufficientBalance）用自定义 error，系统错误（DB timeout）直接返回，别统一转成 fmt.Errorf("xxx: %w") 吞掉原始堆栈
别在 repo 层做 if err != nil { log.Error(...) } —— 日志属于 service 或 handler 的职责