Go中实现MVC本质是自主组织代码分层并明确职责边界，Controller仅解析请求、调用service、构造响应；Model应为含行为的领域对象而非ORM结构体；View指纯渲染逻辑，模板不应含复杂判断，前后端分离时View即JSON响应；依赖须显式注入，避免全局变量与闭包捕获。
Go 语言本身没有强制 MVC 结构，net/http 甚至不带路由或模板引擎——所谓“Golang 中实现 MVC”，本质是**你自己组织代码分层，并明确各层职责边界**。硬套传统 PHP/Java 风格的 MVC 容易导致过度设计，反而让 http.HandlerFunc 变得臃肿、测试困难、依赖混乱。
Controller 层：别写成“万能处理器”
很多人把所有 HTTP 逻辑塞进一个 UserController 方法里：解析参数、校验、调用 service、处理错误、渲染模板……这实际是反模式。
- Controller 应只做三件事：
解析请求（binding）、调用 domain/service 层、构造响应（status/code/body） - 校验逻辑应下沉到
service或独立validator包，避免在 controller 里写if len(req.Name) == 0这类裸判断 - 不要在 controller 里直接操作数据库或调用外部 API；这些必须通过 interface 抽象，方便单元测试 mock
- 示例中常见错误：
c.JSON(200, user)看似简洁，但一旦要加缓存头、ETag、跨域策略，就得反复改 controller —— 正确做法是统一由 middleware 或 response builder 处理
Model 层：不是 ORM struct 的集合
Go 里 type User struct { ID int; Name string } 不等于 MVC 中的 Model。真正的 Model 是包含行为和约束的领域对象，而 Go 的 struct 默认是数据载体。
- Model 应该是 package 内部的、不可导出的结构体 + 导出的方法，例如
NewUser(name string) (*User, error)封装创建规则 - 避免把 GORM 或 SQLX 的
struct直接暴露给 controller 或 template；它们属于 data access 层细节，应转换为 domain model 或 DTO - 如果用
gorm.Model，注意它的ID、CreatedAt等字段会污染领域逻辑；建议用嵌入方式隔离：type User struct { Base gorm.Model; Name string }，且Base不参与业务计算 - 数据库字段名（如
user_name）和 Go 字段名（Name）的映射，应在 repository 层完成，而非靠gorm:"column:user_name"散布在 model 上
View 层：template 不等于 MVC 的 V
Go 的 html/template 是纯渲染工具，它不持有状态、不触发逻辑、不响应事件——所以它只是 View 的“静态输出部分”，不是完整意义上的 View。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 不要在
.html模板里写复杂逻辑：{{if and .User.Admin .User.Active}}应提前算好CanEdit := user.Admin && user.Active传入 - 模板应接收 DTO（data transfer object），而非 domain model；DTO 字段命名可面向展示优化（如
DisplayName而非Name） - 前后端分离项目中，根本不需要服务端模板；此时 View 层退化为 JSON 响应，重点转为 API 设计一致性（如错误格式统一为
{"error": "xxx", "code": "invalid_param"}） - 若用
embed.FS加载模板，注意路径必须是字面量字符串：template.ParseFS(templates, "templates/*.html")，动态拼接路径会导致编译期 embed 失效
Router 和依赖注入：MVC 能否跑起来的关键
没清晰的依赖流向，MVC 就是纸糊的架子。Go 没有 Spring 那样的容器，但可以用函数参数显式传递依赖。
- 避免全局变量初始化 service：
var userService *UserService+init()—— 这让测试无法替换依赖，也隐藏了真实依赖关系 - 推荐用“构造函数注入”：router 初始化时传入 controller 实例，controller 构造时接收 service 接口，service 实现接收 repository 接口
- 使用
chi或gorilla/mux时，不要把 handler 写成闭包捕获变量（如func() http.Handler { return http.HandlerFunc(...) }），而应封装为 struct 方法：u := &UserController{Service: s}; r.Get("/users", u.List) - DI 容器（如
uber/fx）适合中大型项目，但小项目用纯函数组合更轻量、更易调试；关键不是用不用 DI，而是能否在main.go顶部一眼看清整个依赖树
真正难的不是分三层，而是决定哪部分逻辑该放在哪一层、以及当需求变化时（比如用户查询要支持 Elasticsearch+缓存+降级），各层是否能独立演进而不互相撕扯。边界模糊的地方，往往藏在 error 处理、日志埋点、事务控制这些“非业务”细节里。
