Go中不应硬套传统MVC，因包循环、路由耦合和模板侵入业务逻辑等问题；推荐用目录结构表达分层、接口隔离依赖、函数组合替代继承，并按能力域（如auth、payment）组织代码。
MVC 在 Go 里不是“开箱即用”的框架约定，而是需要你主动组织结构、明确职责边界——Go 标准库没有 Controller 或 View 类型，硬套传统 MVC 容易导致包循环、路由耦合或模板侵入业务逻辑。
为什么 Go 项目里直接照搬 Rails/Spring MVC 会出问题
Go 的包管理机制和编译模型决定了：如果把 model、controller、view 拆成三个互相 import 的包，很容易触发循环引用。比如 controller 需要调用 model.User.Get()，而 model 又依赖 view.RenderJSON()（常见于错误封装），就卡死了。
更实际的问题是：Go 的 HTTP 处理函数签名固定为 func(http.ResponseWriter, *http.Request)，它天然就是“控制器入口”，再抽象一层 BaseController 类往往增加间接性却不提升可测性。
无序列表说明典型陷阱：
立即学习“go语言免费学习笔记（深入）”；
-
model包里调用template.Execute()或json.NewEncoder().Encode()—— 这让数据层承担了序列化职责，违反单一职责 - 所有 handler 都写在
main.go里，靠注释分块叫 “MVC” —— 实际只是命名分组，没解决关注点分离 - 用第三方 MVC 框架（如
gin的Engine.Group()+ 自定义中间件）强行模拟 Controller 继承链 —— Go 不支持类继承，最终变成一堆全局函数+闭包，难以单元测试
用标准库实现轻量级 MVC 分层（推荐路径）
核心思路：用目录结构表达意图，用接口隔离依赖，用函数组合代替继承。
一个可行的布局：
cmd/
server/
main.go // 只负责初始化 router、db、logger，不写业务逻辑
internal/
handler/ // 等价于 Controller：只做参数解析、调用 service、写响应
user_handler.go
service/ // 核心业务逻辑，不关心 HTTP 或 DB 实现细节
user_service.go
model/ // 纯数据结构 + 基础校验，不含数据库操作
user.go
repository/ // 数据访问层，实现 model 的持久化（可 mock）
user_repo.go
transport/ // 可选：统一响应包装、错误转 HTTP 状态码
response.go
关键约束：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
handler只 importservice和transport，绝不 importrepository或model（除非是 struct 字面值） -
service的方法参数和返回值用model类型，但不依赖任何具体 DB 实现 —— 它接收的是repository.UserRepository接口 -
repository包里定义接口，postgres/或memory/子包提供实现，这样测试时可注入内存 repo
模板渲染该放在哪一层？
Go 的 html/template 是典型的“View”，但它不该出现在 handler 或 service 中。正确位置是：transport 或独立的 view 包。
例如：
func RenderUserPage(w http.ResponseWriter, user model.User) error {
t := template.Must(template.ParseFiles("templates/user.html"))
return t.Execute(w, user)
}
这个函数属于视图逻辑，它：
- 接收已加工好的
model.User（不是从 DB 直接查出来的*sql.Rows） - 不处理请求参数、不调用 DB、不写 header —— 只做渲染
- 可被多个 handler 复用，也可被 CLI 工具调用生成静态页
如果项目全是 JSON API，那 view 层就退化为 transport.JSONResponse() 这类函数，甚至可以不要。
什么时候该放弃 MVC 标签，改用更贴合 Go 的分层
当团队开始争论 “这个函数该放 controller 还是 service” 时，大概率是分层粒度错了。Go 更习惯按“能力域”而非“MVC 角色”组织代码。
更自然的替代方案：
- 用
pkg/auth封装登录、token 验证、权限检查 —— 它可能同时包含 model（Token）、service（VerifyToken()）、transport（AuthMiddleware()） - 用
pkg/payment聚焦支付流程，内部再拆gateway/、event/、report/—— 而不是把所有 gateway 代码塞进controller - HTTP 路由只负责分发，真正难的是领域模型间的状态流转（比如订单创建后触发库存扣减+通知发送），这部分用
service+event解耦，比 MVC 的“C 协调 M 和 V”更清晰
真正的难点不在怎么命名文件夹，而在定义清楚每个包的 **可变边界**：哪些东西变的时候，其他包完全不用改？那个边界，才是你该画的线。
