1.1 Django 与 MTV 架构全景

1.1 Django 与 MTV 架构全景

本节摘要：Django 是一个"自带电池"的全栈 Web 框架，用 MTV（Model-Template-View）架构组织代码。本节讲清三层各自的职责边界、一次 HTTP 请求在框架内的完整流转，以及框架替你处理了哪些你原本要手写的脏活。理解这张全景图，后面每一章的学习都有坐标系。

一个请求从进门到出门

假设读者在浏览器里访问墨迹博客的首页。这个请求到达 Django 后，并不是直接落到你写的代码上，而是先穿过一条"海关通道"：

# 概念示意：一次请求经过的关键环节（顺序即代码执行顺序）
# 1. WSGI/ASGI 服务器把 HTTP 请求交给 Django
# 2. 根 URL 配置按顺序匹配路径
# 3. 匹配成功的视图函数被调用，拿到 request 对象
# 4. 视图调用模型层读写数据库
# 5. 视图选择模板，传入上下文渲染出 HTML
# 6. 中间件对响应做后处理，返回给浏览器

def article_list(request):          # 第 3 步：视图函数
    articles = Article.objects.all()[:10]   # 第 4 步：模型层
    return render(request, 'blog/list.html',
                  {'articles': articles})   # 第 5 步：模板层
​

上面十几行代码背后，Django 替你完成了：URL 解析与正则匹配、请求对象封装、数据库连接管理、模板引擎查找与编译、上下文渲染、响应编码。如果不用框架，这些每一项都得自己写，而且写得未必更对。

MTV 三层的职责边界

很多教程把 MTV 与 MVC 对号入座，说 Model 对 Model、Template 是 View、View 是 Controller。这个对应关系字面上没错，但对初学者是个干扰项。更实用的理解方式是问三个问题：

边界感是 Django 项目可维护性的根。墨迹博客早期最容易犯的错，是把"只显示已发布文章"的判断写进模板里，结果第 8 章做 Admin 时发现后台也复用这段模板，连带把过滤逻辑也复用了，草稿全被读者看见。正确的位置是模型层加一个自定义管理器，模板只管显示。这类教训在后面章节会反复以不同形式出现。

请求流转全景图

框架替你做了什么

初学者常有错觉："框架限制太多"。换一个角度看，Django 是把 Web 开发二十年来踩过的坑固化成了默认行为。举三个例子。

一是防注入与防 XSS。 模板引擎默认对所有变量做 HTML 转义，你写一个包含脚本标签的用户昵称，页面显示的是原文而不是执行它。除非显式声明安全，否则不会放行。

二是 CSRF 防护。 表单里那块隐藏的令牌、提交时的比对，都由中间件和模板标签自动完成。第 6 章会看到它的工作细节。

三是密码存储。 认证系统默认使用 PBKDF2 派生哈希并自动加盐，改算法时旧哈希能在用户下次登录时透明升级。手写这些逻辑，十个人有九个会留下漏洞。

当然，"自带电池"也有代价：Django 的默认选择偏保守，性能敏感场景需要自己调优（第 11 章的主题），学习曲线前段也比微型框架陡。对墨迹博客这种内容型项目，这笔交换明显划算。

框架的边界感

理解 MTV 分层还有一层常被忽略的收益：知道什么不该框架做。Django 替你处理请求解析、数据库抽象、会话管理，但业务规则、权限颗粒度、数据口径这些事它只提供钩子不提供判断——发布状态该有几种、评论要不要审核、作者归属怎么认定，全是你的领域知识，框架无从代劳。新手常在这条边界上犯两种错：要么把业务逻辑塞进模板或 URL 配置里，让框架的层被业务渗透；要么反过来，期望框架自带某个业务功能，在文档里翻找不存在的配置项。建立边界感的方法很朴素：每写一段代码前问一句这是呈现问题、数据问题还是流程问题，答案分别对应模板层、模型层、视图层，三不沾的逻辑就该重新想归属。这个习惯在墨迹博客全周期里反复被验证：凡是放对层的代码，后续改起来都快；放错层的，都在还债。

本节要点回顾

• MTV 是问题分工：模型答"数据长什么样"，模板答"怎么呈现"，视图答"这个请求做什么"。
• 请求流转顺序：中间件 → URL 路由 → 视图 → 模型/模板 → 响应，这条链路贯穿全册。
• 边界感先于语法：判断写在哪一层，比记住多少 API 更能决定项目命运。
• 框架的默认行为是安全网：转义、CSRF、密码哈希都值得信任，除非你确切知道自己在改什么。

下一节我们把这套架构落成磁盘上的目录——两条命令，一个能跑的骨架。