Go 语言无内置 MVC 框架，MVC 是开发者基于 net/http、结构体和接口手动分层的结果；强行套用传统 MVC 易致过度设计；net/http 不支持自动路由绑定，需第三方库处理参数解析；Model 应为纯数据结构+接口隔离，View 渲染须避免逻辑混杂，边界划分取决于可测性与便利性的权衡。
Go 语言本身没有内置的 MVC 框架，也不鼓励强约定式架构；所谓“Golang MVC”不是标准范式，而是开发者根据业务需要、在 HTTP 路由 + 结构体 + 接口组合基础上手动分层的结果。强行套用传统 MVC（比如 Rails 或 Spring MVC 那套）容易导致过度设计、接口膨胀、测试困难。
为什么 net/http 默认不支持控制器自动路由绑定
Go 的 http.ServeMux 只做路径到 http.Handler 的简单映射，不解析函数签名、不反射调用方法、不管理依赖注入。这意味着：
-
Controller必须显式实现http.Handler或用闭包包装成http.HandlerFunc - 没有默认的
/users/:id参数提取，得靠第三方路由器（如gorilla/mux、chi）或自己解析r.URL.Path - 视图（View）通常只是模板渲染逻辑，不涉及服务端组件生命周期，
html/template本身无状态、无上下文注入机制
如何组织 Model 层才不会和数据库耦合
Model 在 Go 中应是纯数据结构 + 行为方法，而非 ORM 实体。关键点在于隔离数据访问细节：
- 定义接口描述仓储能力，例如：
type UserRepository interface { FindByID(id int) (*User, error) } - 具体实现（如
PGUserRepo或MockUserRepo）只在 main 或 wire 初始化时注入 - Model 结构体避免嵌入
gorm.Model或xorm.Id等框架字段；ID、CreatedAt 这类字段按需添加，不强制继承 - 数据库错误（如
sql.ErrNoRows）不应透出到 Handler 层，应在 Repository 实现中转为领域错误（如user.ErrNotFound）
View 渲染时怎样避免模板与业务逻辑混杂
Go 模板天然不支持逻辑嵌套，但开发者常误用 {{if .User.Admin}} 做权限判断，结果把策略逻辑塞进视图。更合理的方式是：
立即学习“go语言免费学习笔记（深入）”；
- 在 Handler 或 Service 层完成数据预处理，传入已计算好的字段，例如：
CanEdit: user.Role == "admin" - 用
template.FuncMap注册极简辅助函数（如格式化时间），禁止注册数据库查询或外部 API 调用函数 - 模板文件按功能拆分：
_header.html、user/list.html、user/detail.html，通过{{template "header" .}}组合 - 避免在模板里访问
.Request.Context或.Writer—— 这些属于 Handler 职责，不是 View 的输入
真正难的不是分三层，而是决定哪部分该放哪一层：比如用户登录后的 session 验证，放在中间件还是 Controller？密码哈希该在 Model 方法里还是 Service？这些边界没有标准答案，取决于你是否愿意为可测性牺牲一点便利性。
