Go语言无内置MVC框架,但可通过包组织、接口抽象和职责划分实现:Model专注数据与业务规则,Controller协调请求与响应,View仅负责模板渲染或序列化。
Go 语言本身没有内置 MVC 框架(不像 Ruby on Rails 或 Laravel),但完全可以通过包组织、接口抽象和职责划分来清晰实现 MVC 模式。关键不在于框架,而在于逻辑分层意识和松耦合设计。
Model 层负责数据结构定义、数据库操作、校验逻辑和核心业务规则,不依赖 HTTP、路由或模板。通常放在 model/ 目录下:
User、Post)user.Save() 或独立的 userRepo.Create())Controller 是 HTTP 请求的入口,负责接收参数、调用 Model 处理业务、决定返回什么视图或数据。它不处理数据细节,也不渲染 HTML:
func (c *PostController) Show(w http.ResponseWriter, r *http.Request) 中只调 post, err := c.repo.FindByID(id),然后交给 View 渲染或返回 JSONView 层仅负责将数据转换为客户端可读格式(HTML、JSON、XML),禁止包含 if/for 以外的业务判断:
templates/ 目录,用 html/template 加载map[string]interface{} 或专用 ViewModel)传给模板,模板只做字段渲染和简单循环json.NewEncoder(w).Encode(data),无需额外“View”文件,此时 View 即序列化动作本身一个轻量但清晰的目录组织示例:
m
ain.go —— 启动入口,注册路由controller/ —— 各资源控制器(user_controller.go)model/ —— 实体定义 + 仓储接口及实现(user.go, user_repo.go)view/ —— 模板文件(user/show.html)或 JSON 渲染辅助函数router/ —— 路由配置(用 net/http 或 gorilla/mux)不复杂但容易忽略的是:MVC 在 Go 中不是靠工具生成的代码,而是靠开发者每天写代码时问自己一句——“这个逻辑放在这里,是否还能被 CLI 命令或 gRPC 接口复用?” 如果答案是肯定的,那它大概率属于 Model;如果只能用于 Web 响应,才考虑放在 Controller 或 View。