一、实验目的本实验旨在通过自定义 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 函数视图与类视图函数视图FBVFunction-Based View是以函数形式定义的视图通过函数参数接收 request 对象根据 request.method 属性判断请求类型并进行处理。FBV 优点是简单直接缺点是代码复用性较差。类视图CBVClass-Based View是以类形式定义的视图继承自 Django 提供的 View 基类。CBV 根据 HTTP 方法GET、POST 等自动分发到对应的处理方法get、post 等通过继承和 Mixin 可以实现代码复用。CBV 优点是结构清晰、易于继承复用缺点是学习曲线稍高。三、实验步骤3.1 中间件实现在应用目录下创建中间件文件 blog/middleware_trace.py实现自定义中间件类 RequestTraceMiddleware图 1 middleware_trace.py — 自定义中间件实现代码截图自 PyCharm3.2 视图实现在应用目录下创建视图文件 blog/views_trace.py分别实现 FBV 和 CBV 两种视图。图 2 views_trace.py — FBV 函数视图实现截图自 PyCharm图 3 views_trace.py — CBV 类视图实现截图自 PyCharm3.3 路由配置在项目 URL 配置文件 djangoblog/urls.py 中添加视图导入和路由映射URL路径视图类型视图名称/trace/fbv/normal/FBVfbv_normal/trace/fbv/exception/FBVfbv_exception/trace/cbv/normal/CBVCBVNormal/trace/cbv/exception/CBVCBVException表 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__中间件初始化时2process_request每次请求必执行3process_view路由匹配成功后4视图执行视图逻辑执行阶段5process_exception视图抛出异常时可选6process_response每次响应前必执行表 3 中间件方法执行顺序关键发现process_request 和 process_view 在任何情况下都会被执行process_exception 仅在视图抛出异常时才会被调用process_response 无论如何都会执行用于记录最终响应状态。五、FBV 与 CBV 视图模式对比分析5.1 定义方式对比特性FBV函数视图CBV类视图定义形式def 函数class 类继承 View请求接收函数参数 requestself.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 开发、性能优化和安全防护具有重要的实践意义。