分层架构旨在解决gin项目中controller膨胀、测试困难、数据库耦合、业务逻辑无法复用四大问题；需按依赖方向划分层级，上层仅依赖下层接口，通过构造函数注入依赖，并规范接口定义（含context、命名、职责单一）。
分层架构不是为了“看起来更专业”，而是为了解决 Gin 项目中 Controller 膨胀、测试困难、数据库耦合、业务逻辑无法复用这几个具体问题。直接在 handler 里写 db.Where(...).First() 或调用第三方 API，短期快，长期难改、难测、难换数据源。
为什么 Gin 项目容易退化成“伪 MVC”？
Gin 本身不强制分层，gin.Context 可以被任意 handler 直接使用，导致常见反模式：
- Handler 里混着参数校验、DB 查询、if/else 业务判断、HTTP 状态码返回 —— 一行
c.JSON(200, data)前可能有 20 行逻辑 - Service 层缺失，或只是把 DB 操作换个包名搬过去，没抽象接口，无法 mock
- Model 层同时承担数据库 struct（带
gorm:"column:name"）和 API 响应结构体职责，字段变更牵一发而动全身 - 测试时必须启动真实数据库，
go test变成集成测试，CI 耗时飙升
分层边界怎么划？关键看“谁该知道谁”
分层不是按文件夹切，而是按依赖方向切。Gin 项目中，真正的分层约束只有这一条：上层只能依赖下层的接口，不能依赖具体实现。例如：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
handler/user_handler.go只能持有service.UserService接口变量，不能是*userServiceImpl -
service/user_service.go只能调用repo.UserRepo接口，不能直接 newgorm.DB或写 SQL -
repo/user_repo.go可以依赖gorm.DB，但对外只暴露方法签名，如GetByID(ctx context.Context, id uint) (*model.User, error) -
model/user.go不依赖任何其他层，纯 struct 定义；建议拆成model.User（DB 映射）和dto.UserResponse（API 输出），避免字段污染
依赖注入怎么做才不绕弯？
Gin 没内置 DI 容器，硬写 newUserService(newUserRepo(db)) 会迅速失控。推荐两种轻量方案：
- 用构造函数参数传递：在
main.go中统一初始化所有依赖，再逐层注入。例如：userHandler := NewUserHandler(userService)，userService := NewUserService(userRepo)，userRepo := NewUserRepo(db) - 用配置对象封装：定义
type Config struct { DB *gorm.DB; Redis *redis.Client }，各层只取自己需要的字段，避免强依赖全部组件 - 不推荐早期引入第三方 DI 库（如 wire、dig），除非团队已明确需要自动代码生成或复杂生命周期管理；多数项目手写初始化更可控、调试更直观
接口定义最容易忽略的三个细节
Go 的 interface 是解耦核心，但写错就白搭：
- 接口方法参数尽量用
context.Context开头，否则无法做超时控制或链路追踪 —— 别写GetByID(id uint) (*User, error)，要写GetByID(ctx context.Context, id uint) (*User, error) - 接口名别带 “Impl” 或 “Interface”，直接叫
UserRepo，实现叫gormUserRepo；调用方看到uRepo.GetByID(...)就知道是数据访问，不关心底层是 GORM 还是 PostgreSQL 原生驱动 - 一个接口只服务一个角色：不要让
UserRepo同时提供Create、Update、SendEmail；后者属于 Service 层职责，Repo 只管存取
分层真正难的不是写法，而是每次新增功能时，下意识问一句：“这个逻辑，放在哪一层它才不会被另一个业务重复实现，又不会因为换数据库而重写？” 答案往往不在代码里，而在你画的第一张接口调用草图上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
