一、实验目的
本实验旨在通过自定义 Django 中间件，深入理解 Django 请求处理流程中中间件的工作机制。具体实验目标包括：
- 掌握自定义 Django 中间件的实现方法，重写 process_request、process_view、process_exception 和 process_response 四个核心方法
- 理解 Django 请求处理生命周期中各阶段方法的执行时机与调用顺序
- 分别实现函数视图（FBV）和类视图（CBV），掌握两种视图模式的编写方式
- 验证异常场景下中间件的异常处理机制，观察 process_exception 方法的触发条件
- 对比 FBV 与 CBV 两种视图模式的特点，分析其适用场景
二、实验原理与核心概念
2.1 Django 中间件概述
Django 中间件是嵌入 Django 请求/响应处理管道中的钩子框架，它是一个轻量级的、基于类的过滤器，可以在请求到达视图之前和响应返回客户端之前对请求和响应进行处理。中间件以链式结构组织，Django 会按照 MIDDLEWARE 配置列表中的顺序依次调用各个中间件。
每个中间件可以重写以下四个核心方法：
- process_request(self, request)：在 Django 执行 URL 路由匹配之前调用，接收 request 对象，可用于请求预处理、权限验证、日志记录等
- process_view(self, request, view_func, view_args, view_kwargs)：在 URL 路由匹配成功后、调用视图函数之前调用，可获取视图函数信息
- process_exception(self, request, exception)：当视图函数抛出异常时调用，用于异常捕获、错误日志记录、自定义错误响应等
- process_response(self, request, response)：在响应返回客户端之前调用，可修改响应内容、添加响应头等
2.2 请求处理流程
Django 请求处理的完整流程如下：
- 客户端发送 HTTP 请求
- 中间件链执行 process_request 方法（按 MIDDLEWARE 顺序）
- URL 路由匹配
- 中间件链执行 process_view 方法（按 MIDDLEWARE 顺序）
- 执行视图函数 / 类视图
- 若无异常，执行 process_response 方法；若存在异常，执行 process_exception 方法
- 响应返回客户端
2.3 函数视图与类视图
函数视图（FBV，Function-Based View）是以函数形式定义的视图，通过函数参数接收 request 对象，根据 request.method 属性判断请求类型并进行处理。FBV 优点是简单直接，缺点是代码复用性较差。
类视图（CBV，Class-Based View）是以类形式定义的视图，继承自 Django 提供的 View 基类。CBV 根据 HTTP 方法（GET、POST 等）自动分发到对应的处理方法（get、post 等），通过继承和 Mixin 可以实现代码复用。CBV 优点是结构清晰、易于继承复用，缺点是学习曲线稍高。
三、实验步骤
3.1 中间件实现
在应用目录下创建中间件文件 blog/middleware_trace.py，实现自定义中间件类 RequestTraceMiddleware：
图 1 middleware_trace.py — 自定义中间件实现代码（截图自 PyCharm）
3.2 视图实现
在应用目录下创建视图文件 blog/views_trace.py，分别实现 FBV 和 CBV 两种视图。
图 2 views_trace.py — FBV 函数视图实现（截图自 PyCharm）
图 3 views_trace.py — CBV 类视图实现（截图自 PyCharm）
3.3 路由配置
在项目 URL 配置文件 djangoblog/urls.py 中添加视图导入和路由映射：
URL路径 | 视图类型 | 视图名称 |
/trace/fbv/normal/ | FBV | fbv_normal |
/trace/fbv/exception/ | FBV | fbv_exception |
/trace/cbv/normal/ | CBV | CBVNormal |
/trace/cbv/exception/ | CBV | CBVException |
表 2 URL 路由映射表
3.4 中间件注册
在项目配置文件 djangoblog/settings.py 的 MIDDLEWARE 列表中进行注册，将追踪中间件放置在最前面以确保最先执行：
MIDDLEWARE = [
#追踪中间件 - 放在最前面确保最先执行
'blog.middleware_trace.RequestTraceMiddleware',
# Django内置中间件
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.middleware.gzip.GZipMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.http.ConditionalGetMiddleware',
]
3.5 实验运行
- 启动 Django 开发服务器：python manage.py runserver 127.0.0.1:8000
- 使用 curl 或浏览器访问各测试 URL，观察终端输出日志
- 分析日志输出，验证中间件执行顺序
四、实验结果与分析
4.1 正常请求流程
访问正常视图 /trace/fbv/normal/ 时，终端输出的日志顺序如下：
=== RequestTraceMiddleware初始化 ===
[process_request]路径: /trace/fbv/normal/, 方法: GET
[process_view]视图: fbv_normal, 路径: /trace/fbv/normal/
[FBV Normal View]执行正常逻辑
[process_response]状态码: 200, 路径: /trace/fbv/normal/
分析：正常请求流程中，中间件各方法按以下顺序执行：
- 中间件初始化（__init__ 方法）
- process_request：请求进入时首先执行，完成请求路径和方法的记录
- process_view：路由匹配后执行，获取视图函数名称
- 视图逻辑执行：视图函数正常返回响应
- process_response：响应返回前执行，记录 HTTP 状态码
4.2 异常请求流程
访问异常视图 /trace/fbv/exception/ 时，终端输出的日志顺序如下：
=== RequestTraceMiddleware初始化 ===
[process_request]路径: /trace/fbv/exception/, 方法: GET
[process_view]视图: fbv_exception, 路径: /trace/fbv/exception/
[FBV Exception View]准备抛出异常
[process_exception]异常: ValueError: FBV 主动抛出的异常
[process_response]状态码: 500, 路径: /trace/fbv/exception/
分析：异常请求流程与正常流程的区别在于：
- 前四个阶段与正常请求相同
- 视图抛出异常后，process_exception 方法被触发执行，记录异常信息
- process_response 依然执行，但返回的状态码为 500（服务器内部错误）
4.3 执行顺序验证
通过日志输出可以确认，中间件各方法的执行顺序严格遵循 Django 框架规范：
执行顺序 | 方法 | 执行条件 |
1 | __init__ | 中间件初始化时 |
2 | process_request | 每次请求必执行 |
3 | process_view | 路由匹配成功后 |
4 | 视图执行 | 视图逻辑执行阶段 |
5 | process_exception | 视图抛出异常时（可选） |
6 | process_response | 每次响应前必执行 |
表 3 中间件方法执行顺序
关键发现：process_request 和 process_view 在任何情况下都会被执行；process_exception 仅在视图抛出异常时才会被调用；process_response 无论如何都会执行，用于记录最终响应状态。
五、FBV 与 CBV 视图模式对比分析
5.1 定义方式对比
特性 | FBV函数视图 | CBV类视图 |
定义形式 | def 函数 | class 类（继承 View） |
请求接收 | 函数参数 request | self.request |
方法分发 | 手动判断 request.method | 自动分发到 get/post 等方法 |
代码组织 | 分散 | 集中（类方法） |
表 4 FBV 与 CBV 定义方式对比
5.2 代码示例对比
FBV 实现：
def fbv_normal(request):
if request.method == 'GET':
return JsonResponse({"status": "success"})
CBV 实现：
class CBVNormal(View):
def get(self, request):
return JsonResponse({"status": "success"})
5.3 优缺点分析
视图类型 | 优点 | 缺点 |
FBV | 简单直接、易于理解、适合简单逻辑 | 代码重复、可维护性差、不支持继承 |
CBV | 结构清晰、易于继承复用、代码复用率高 | 学习曲线稍高、配置相对复杂 |
表 5 FBV 与 CBV 优缺点分析
5.4 适用场景
FBV适用场景：
- 简单的单个页面、无需复用的小型视图
- 快速原型开发
CBV适用场景：
- 复杂的业务逻辑、需要代码复用的大型项目
- RESTful API 设计
5.5 中间件视角下的对比
从中间件执行日志可以观察到，FBV 和 CBV 在中间件处理流程中完全一致：
- process_view 阶段记录的视图名称不同（fbv_normal vs CBVNormal）
- 视图执行阶段的日志记录不同（[FBV Normal View] vs [CBV Normal View]）
- process_response 阶段均正常执行，返回状态码 200
结论：在中间件层面，FBV 和 CBV 的处理流程完全等价，区分仅存在于视图定义和调用方式层面。
六、实验结论与总结
6.1 实验结论
通过本实验，可以得出以下结论：
- 中间件执行顺序：中间件各方法按照固定顺序执行，初始化 → process_request → process_view → 视图 → process_exception（可选）→ process_response
- 方法触发条件：process_request 和 process_response 在每次请求中都会执行；process_view 在路由匹配成功后执行；process_exception 仅在视图抛出异常时执行
- 中间件位置影响：中间件在 MIDDLEWARE 列表中的位置决定了执行顺序，越靠前越先执行
- FBV 与 CBV 等价性：从中间件视角看，FBV 和 CBV 的处理流程完全一致，中间件不关心视图的具体实现方式
- 异常处理机制：中间件的 process_exception 方法可以捕获视图异常，返回自定义响应来替代 500 错误页面
6.2 实验收获
本实验加深了对 Django 框架请求处理机制的理解，掌握了自定义中间件的实现方法，区分了 FBV 和 CBV 两种视图模式的编写方式和适用场景。这些知识对于进行 Django Web 开发、性能优化和安全防护具有重要的实践意义。
