路面垃圾检测系统：Django+MySQL+YOLO深度学习实战解析-开发者社区

简介：这是一套面向计算机专业本科生的毕业设计级路面垃圾智能检测系统完整实现，基于Python深度学习与Django Web框架构建，解决城市环卫管理中垃圾识别效率低、任务闭环难的问题。资源包含1707个文件，涵盖63个核心Python模块（含模型训练与推理逻辑）、47个JavaScript前端交互脚本、37个CSS样式文件及大量SVG图标资源，支撑起用户端任务领取、图片上传复核与管理员端图像/视频/摄像头多模态识别等完整业务流；压缩包体积465.98MB，已适配Python 3.7、MySQL 5.7+及PyCharm开发环境，部署后可直接运行。目前已有83人学习下载，提供完整前后端源码、MySQL建库SQL脚本、详细说明文档、答辩用PPT及毕业论文（LW），代码结构清晰、模块职责分明，特别适合毕设选题参考、课程设计实战与深度学习Web落地项目学习。

1. 项目概述与技术选型

1.1 核心需求解析

第一次看到这个项目标题，你可能觉得它就是个普通的学生作业，但实际上仔细拆解下来，这里面涉及的技术栈覆盖面相当广。一个完整的路面垃圾检测系统，从用户角度看是什么？上传一张路面照片，系统自动检测出哪里有垃圾、是什么类型的垃圾、数量多少，然后把这些信息存下来供后续查询统计。从开发者角度看，它至少包含四层东西：前端交互页面、后端业务逻辑、深度学习推理模块、数据库存储。

我当年做类似项目的时候，最深的体会是：这类毕设项目的难点压根不在算法本身，而在于怎么把算法“塞”进web系统里，让整个链路跑通。单独跑YOLO检测一张图片，十几行代码搞定，但要做成系统，涉及文件上传、模型加载生命周期管理、结果序列化、数据库写入、前端展示，每个环节都有坑。

项目选择了django + mysql + 深度学习目标检测这个组合，从毕设评审角度来说非常合理。django是python生态里最成熟的web框架，自带admin后台和ORM，能快速搭建业务模块；mysql是应用最广的关系型数据库，面试和答辩时都有话可说；深度学习部分用的是目标检测算法，通常以YOLO系列为主，因为YOLO在工业界的普及度最高，部署资料最丰富，答辩时解释原理也最容易讲清楚。

1.2 为什么是django而不是Flask或FastAPI

这个问题我几乎每次都会被问到。直观上看，Flask更轻量，几行代码就能起一个服务，那为什么毕设还要选django？

核心原因有三点。第一，django自带admin后台。路面垃圾检测系统必然需要管理端功能——管理用户、查看检测记录、管理垃圾类型标签，如果用Flask，这些全部要从零手写。django的admin能帮你自动生成增删改查页面。第二，django有ORM层，操作mysql不需要写原生SQL，对于不擅长数据库的学生来说是巨大的减压。第三，django的MTV架构层次分明，写进论文里好画图、好描述，答辩时逻辑清晰。

当然django也有缺点，比如同步阻塞模型在高并发下表现一般，但这是毕设项目，只是给老师和答辩评委看的演示系统，完全够用。如果聊到部署方式，通常会采用django + nginx + gunicorn，django处理业务逻辑，nginx管静态文件和反向代理。

1.3 深度学习模型选型说明

路面垃圾检测属于目标检测任务，可选项有Faster R-CNN、SSD、YOLO系列。考虑到这是毕设项目，我建议优先考虑YOLOv5或者YOLOv8。原因特别实际：

YOLOv5的训练和推理生态最成熟，网上开箱即用的预训练权重和数据集非常多
YOLOv5的代码结构比v8更清晰，适合答辩时讲原理
对硬件要求相对友好，一张普通的GPU（哪怕只有4GB显存）也能跑

如果题目里写的是“深度学习”而没有指定具体算法，YOLOv5是当前最优解。如果你想把项目做得更有深度，在论文里加一些模型改进的章节（比如替换主干网络、加注意力机制），YOLOv5的代码也比较容易做改动实验。

1.4 项目文档结构解读

购买或下载这类完整源码包，你通常会看到这些文件：源码主目录、mysql数据库脚本（.sql文件）、说明文档（通常叫README或者项目说明.docx）、LW（论文文档）、PPT答辩稿。很多人不重视说明文档，实际上这部分特别重要——毕设项目收到手里的第一件事是看数据库脚本和依赖清单，而不是急于去跑代码。

我见过太多人拿到项目源码第一步就在主目录下python manage.py runserver，然后疯狂报错。正确顺序应该是：先看README或说明文档，确认python版本、django版本、依赖库清单；再导入数据库脚本到mysql，确定账号密码；然后修改django的settings.py数据库配置；最后才运行。顺序错了，配置没改对，肯定起不来。

2. 系统架构与核心功能设计

2.1 整体架构分层

以一个标准的django + 深度学习检测系统为例，整体分层是这样的：

┌─────────────────────────────────────────────┐ │ 表现层（Template + JS + CSS） │ │ 垃圾检测页面、历史记录页面、管理后台 │ ├─────────────────────────────────────────────┤ │ 路由层（urls.py 路由分发） │ ├─────────────────────────────────────────────┤ │ 业务层（views.py 处理请求） │ │ 用户管理模块 / 图片上传模块 / 检测调度模块 │ │ 记录查询模块 / 统计报表模块 │ ├─────────────────────────────────────────────┤ │ 服务层（深度学习推理引擎） │ │ 模型加载 / 图片预处理 / 推理 / 结果解析 │ ├─────────────────────────────────────────────┤ │ 数据层（MySQL） │ │ 用户表 / 检测记录表 / 垃圾类型表 │ └─────────────────────────────────────────────┘

这个分层最核心的一点，是把深度学习推理和django的业务逻辑解耦。模型推理是耗时操作，处理一张图片可能需要几百毫秒到几秒不等，如果直接放在views.py里同步执行，用户会一直转圈等待。合理的做法是把模型加载做成单例，整个应用只加载一次，后续请求重复使用，相比每次请求都重新加载模型，响应速度能提升几十倍。

2.2 核心功能模块拆解

一个完整的检测系统至少应该有五个功能模块，缺一不可。

用户模块负责注册和登录。django自带的auth系统可以直接用，也可以自己写一个简单的用户表。要注意的是，如果用了django自带的User模型，扩展字段比较麻烦，毕设阶段建议自定义用户表，虽然多写点代码，但实际上更好控制。

图片上传模块是整个系统的入口。前端需要一个表单，接收jpg/png图片，后端要做格式校验、大小限制，还要处理文件名的重命名，避免中文名导致的编码问题。图片最终会保存在项目的media目录下，数据库里存的是文件路径。

检测调度模块是核心，接收图片路径，调用深度学习模型做推理，把检测结果（垃圾类别、置信度、边界框坐标）解析成JSON格式返回。这里有一个关键细节：模型的输入需要resize到固定尺寸（比如640x640），检测出来的边界框坐标是相对于resize后图片的，必须进行坐标变换映射回原图，否则前端画框的位置是偏的。

记录管理模块负责把检测结果写入mysql。除了基础字段（图片路径、检测时间），还要存检测出的垃圾类别和数量。这里建议用两个关联表，一个存检测记录，一个存检测到的每个垃圾项，方便后面做统计。

统计模块是加分项。可以统计一段时间内检测到多少垃圾，按垃圾类型分组展示，哪种垃圾出现最多，用柱状图或饼图可视化。这部分在论文和答辩中都很有价值，能展示系统的数据价值。

2.3 数据库表结构设计

数据库表设计是整个系统能否顺畅运行的基础。以下是我结合常见需求和字段扩展总结的一个比较完善的表结构：

检测记录表（detect_record）：

id（主键）
user_id（外键，关联用户表）
image_path（原图存储路径）
result_image_path（标注了检测框的结果图路径）
total_count（检测到的垃圾总数）
created_time（检测时间）

检测结果明细表（detect_result）：

id（主键）
record_id（外键，关联检测记录）
class_name（垃圾类别，如plastic_bottle、cigarette_butt、paper_cup等）
confidence（置信度，0到1之间）
x_min、y_min、x_max、y_max（边界框坐标，归一化后的值或者原图像素值）

垃圾类别表（garbage_type）：

id
class_name（英文标识，和模型训练时的类别名称对应）
class_label（中文名称）
description（描述）

设计时有个必须注意的地方：垃圾类别名称一定要和模型训练时的类别名称保持一致。如果你用的是COCO数据集的80类预训练权重，那类别名称就是person、bicycle、car这些，但路面垃圾检测需要自己训练或者用专门的垃圾分类数据集，类别名称也会不同。数据库表里存的类别和模型输出不匹配，检测结果就会乱套。

2.4 为什么需要MySQL而不是SQLite

很多django初学者会问，django默认用的是SQLite，为什么毕设非要换mysql？

从开发角度来说，SQLite确实更方便，零配置开箱即用。但从毕设角度来说，mysql有三点无可替代的价值：

第一，mysql是简历上写的最多的数据库，面试高频考察点，用mysql做毕设能同时复习面试内容。第二，mysql在Windows和Linux上都能稳定部署，而SQLite在高并发写场景下会锁库，如果你在答辩演示时快速多次点击识别，SQLite可能直接报database is locked。第三，mysql的Workbench等可视化工具成熟，答辩时展示表结构更直观。

要配置mysql连接，需要安装mysqlclient或者pymysql。这里有一个小坑：mysqlclient在Windows上经常编译失败，推荐在Python 3.10以下版本使用pymysql，简单省事。具体配置就是在项目__init__.py里添加pymysql.install_as_MySQLdb()，然后在settings.py里配置DATABASES。

3. 深度学习模型集成实操

3.1 模型文件与依赖准备

整个项目里最核心的深度学习部分，最关键的文件是模型权重文件，通常命名为best.pt或者yolov5s.pt。best.pt是你自己训练得到的权重，在测试集上表现最好的模型；yolov5s.pt是官方预训练权重，可以直接用来做目标检测但没有专门针对路面垃圾优化。

不管你用哪个权重，都要确认它对应的类别配置文件（data.yaml或classes.txt）。这个文件定义了模型输出每一个框对应什么类别，比如：

0: plastic_bottle 1: cigarette_butt 2: paper_cup 3: plastic_bag 4: leaves

模型输出是一个形状为(N, 6)的tensor，N代表检测到几个目标，每行的6个值分别是：x_center、y_center、width、height、confidence、class_id。做推理代码时，把class_id映射成类别名称，这一步必须用你训练时定义的类别顺序，不能随便改。

3.2 推理模块的工程化封装

把YOLO推理封装成一个独立的服务类，是很多人在毕设阶段容易忽视的事。别把推理代码直接写在views.py里，一定要单独抽一层出来。我习惯的做法是写一个detector.py文件，核心代码如下：

import torch import cv2 import numpy as np class GarbageDetector: _instance = None def __new__(cls, *args, **kwargs): if cls._instance is None: cls._instance = super().__new__(cls) return cls._instance def __init__(self, weights_path, device='cpu'): self.model = torch.hub.load( 'ultralytics/yolov5', 'custom', path=weights_path, force_reload=False ) self.model.conf = 0.25 # 置信度阈值 self.model.iou = 0.45 # NMS的IoU阈值 self.model.classes = None # 不过滤类别 self.device = device def predict(self, image_path): img = cv2.imread(image_path) img_rgb = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) results = self.model(img_rgb) return results

这里做了三件很重要的事：第一，用单例模式，保证整个django进程生命周期内模型只加载一次，这是性能的关键；第二，设置置信度阈值和IoU阈值，控制检测的敏感度和重叠框的过滤；第三，返回的results已经封装好了，可以直接用results.pandas().xyxy[0]拿到DataFrame格式的检测结果，非常方便。

3.3 把模型集成到Django中的关键细节

在django中调用模型，有一个特别容易踩坑的地方：模型加载的位置。很多人在views.py顶部就直接加载模型，在开发服务器下这没问题，但一旦用了gunicorn或uwsgi部署，worker进程会fork，如果模型在import时加载，每个worker都会保留一份模型拷贝，内存会直接爆炸。我在实际项目中就把内存从2GB吃到了8GB。

另一个坑是线程安全。django的视图可能被多线程并发调用，如果多个请求同时进入模型推理，PyTorch的模型推理默认不是线程安全的，可能出现CUDA error或者推理结果错乱。解决方案是加线程锁，或者确保在CPU环境下推理同一批请求时足够安全。最简单的做法是：

import threading from .detector import GarbageDetector detector = GarbageDetector() lock = threading.Lock() def detect_view(request): if request.method == 'POST': # 处理上传 with lock: results = detector.predict(image_path) # 解析结果

虽然加锁会让并发请求排队，但换来的是稳定可靠，在毕设答辩现场绝对不能出问题。

3.4 图片预处理与结果后处理

推理环节的另一个关键细节是图片预处理与结果后处理。YOLO的输入尺寸默认是640x640，如果你的测试图片分辨率很大（比如手机拍的是4032x3024），直接传给模型会先被resize，导致检测小目标垃圾的效果变差。我的建议是：在上传前就做一次压缩，统一限制图片最长边为1280px，既能保留足够的目标细节，又能显著减少推理时间。

后处理部分，需要在返回JSON前，把检测结果的边界框坐标从640x640的坐标系映射回原图坐标系。如果检测结果直接用了模型输出的坐标，前端画框会出现错位。具体做法是计算缩放比例，分别对x和y坐标做映射：

def map_coordinates(box, orig_w, orig_h): # box: [x1, y1, x2, y2] 在模型输入尺寸下的坐标 scale_x = orig_w / 640 scale_y = orig_h / 640 x1, y1, x2, y2 = box return [int(x1 * scale_x), int(y1 * scale_y), int(x2 * scale_x), int(y2 * scale_y)]

4. 系统功能实现与代码解析

4.1 用户登录注册模块实现

登录注册模块是整个系统的基础入口。django的auth框架自带登录验证和session管理，但直接用它可能和自定义用户表有冲突。我建议用一个折中方案：自定义一个UserProfile模型，继承AbstractUser，这样既能用django的认证逻辑，又能扩展自定义字段。

创建应用和模型后，需要同步执行两条命令：python manage.py makemigrations和python manage.py migrate。很多人忽略了一个细节：如果你在项目启动后才创建了自定义用户模型，并且已经执行过migrate，就要先把数据库里的django_admin_log、auth_user等关联表清空重新迁移，否则会报字段冲突。

登录视图的核心逻辑比较简单，接收POST请求，校验用户名密码，写入session，重定向到首页。注册视图需要做查重、密码确认校验。前端页面用django模板语法即可，不用单独前后端分离。

4.2 图片上传与垃圾识别完整流程

垃圾识别的完整流程是这样的：

用户上传图片 -> 前端把图片POST到/detect/-> 后端保存图片文件 -> 调用推理模块 -> 生成标注结果图 -> 把记录写入数据库 -> 返回结果给前端展示。

前端页面上我用了一个简单的表单，加上Canvas绘制检测框。后端在保存图片时要用uuid重命名：

import uuid def upload_image(request): if request.method == 'POST': upload_file = request.FILES.get('image') if not upload_file: return JsonResponse({'code': 400, 'msg': '未选择图片'}) ext = os.path.splitext(upload_file.name)[-1].lower() if ext not in ['.jpg', '.jpeg', '.png', '.bmp']: return JsonResponse({'code': 400, 'msg': '不支持的图片格式'}) # 生成唯一文件名 filename = f"{uuid.uuid4().hex}{ext}" file_path = os.path.join(settings.MEDIA_ROOT, 'upload', filename) with open(file_path, 'wb') as f: for chunk in upload_file.chunks(): f.write(chunk)

这里的重点是：一定要用upload_file.chunks()而不是read()，chunks()是django专门为大文件处理设计的分块读取方法，不会一次性把整个文件加载进内存。

推理完成后，用OpenCV在图片上画检测框和标签，另存到media目录的result子目录下。为了演示效果更好，我建议把检测框画得醒目一点，垃圾类别用中文显示，置信度保留两位小数。字体文件如果是中文，记得从系统字体目录拷贝一个.ttf到项目里，否则OpenCV的putText不支持中文，画出来的全是乱码。

4.3 历史记录与数据统计模块

历史记录页面通过django的ORM查询数据库，展示最近N条检测记录。分页用django自带的分页器Paginator，每页10条。记录列表里展示缩略图、垃圾数量、检测时间。点击可以进入详情页，看到带标注框的大图和检测明细列表。

数据统计模块是一个值得做得更丰富的地方。最简单的方案，用echarts的饼图统计不同垃圾类型的占比，用柱状图展示最近一周的检测数量。为了让前端拿到统计数据，后端写一个接口，用ORM的annotate+count聚合查询：

from django.db.models import Count from .models import DetectResult def statistics(request): # 按垃圾类别统计数量 type_stats = ( DetectResult.objects .values('class_name') .annotate(total=Count('id')) .order_by('-total') ) return JsonResponse({'code': 200, 'data': list(type_stats)})

这种代码在论文里也很好写清楚：先按类别分组，再用聚合函数统计每个组有多少条记录，最后按数量降序排列。

4.4 Django管理后台配置

django的admin后台自带功能其实已经很强大了，但默认配置比较朴素，建议在admin.py里做一点定制：

from django.contrib import admin from .models import UserProfile, DetectRecord, DetectResult @admin.register(DetectRecord) class DetectRecordAdmin(admin.ModelAdmin): list_display = ('user', 'image_path', 'total_count', 'created_time') list_filter = ('created_time',) search_fields = ('user__username',)

注册admin之后，登录/admin/就能直接管理数据库记录，对于答辩演示很有帮助——有些评委可能会说“那你给我看看之前检测了多少次垃圾”，直接打开admin筛选就行了。

5. 部署配置与常见问题排查

5.1 本地运行环境准备清单

把项目从压缩包解压后，正确启动步骤应该是这样的：

创建Python虚拟环境，建议用conda创建Python 3.8或3.9环境（PyTorch对老版本的兼容性比较好）
安装依赖，pip install -r requirements.txt，注意requirements里可能会有版本冲突
导入数据库，用mysql创建库，然后mysql -u root -p databasename < dump.sql
修改settings.py中的DATABASES配置，改成你自己的mysql账号密码
静态文件和media文件的路径检查，确认目录存在且有写权限
python manage.py makemigrations && python manage.py migrate（如果数据库已经是完整的可以跳过）
python manage.py createsuperuser创建管理员账号
python manage.py runserver启动开发服务器

5.2 数据库连接与配置问题排查

migrate时报django.db.utils.OperationalError: (2003, "Can't connect to MySQL server on ...")，这是最常见的错误，原因要么是mysql服务没启动，要么是host/port配置不对。

Windows上确认mysql是否启动，可以在命令行执行net start mysql（具体服务名取决于安装时设置）。还有一个非常容易掉的坑：mysql 8.0以上默认使用caching_sha2_password认证方式，但PyMySQL对这种方式支持得不够好，如果你是用PyMySQL，建议在mysql里把用户认证方式改成mysql_native_password：

ALTER USER 'root'@'localhost' IDENTIFIED BY 'your_password'; ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';

另外，如果导入.sql文件时报语法错误，大概率是.sql文件是旧版mysql导出的，而你用的是mysql 8.0+，这种时候可以用mysql -u root -p --default-character-set=utf8来指定字符集导入，避免中文乱码。

5.3 深度学习环境相关坑点排查

深度学习环境在本地部署时可以说是项目报错的重灾区，这里把我踩过高频的坑集中说一遍。

Windows下装torch时经常遇到下载慢和依赖冲突。解决方案是使用国内镜像源：pip install torch torchvision -i https://pypi.tuna.tsinghua.edu.cn/simple。如果用的是pip下载torch，建议直接去pytorch.org官网复制对应的pip命令，而不是在requirements里写torch裸版本号，因为不同CUDA版本对应的torch版本不同，裸版本号很容易装成CPU版本或者版本不匹配。

torch.hub.load加载YOLOv5时经常报ModuleNotFoundError: No module named 'models'之类的错，这是因为torch.hub在联网下载仓库时，路径和发布版本不一致。解决方法是在最终部署时，直接把用到的YOLOv5仓库代码一起放进项目里，用from yolov5.models.experimental import attempt_load代替torch.hub，从源头避免联网依赖。

推理时报RuntimeError: CUDA out of memory，说明显存不够。如果你想要在演示电脑上运行，或者根本没有独立显卡，建议直接在detector.py里强制指定device='cpu'，虽然速度慢一些，但胜在稳定，不会因为显存不足而崩溃。CUP推理一张640x640的图片大约300-800ms，演示环境下完全能接受。

5.4 前后端联调与静态资源配置

django开发模式下，runserver能直接托管静态文件，但部署到生产环境时经常出现样式丢失、图片加载失败的情况。在settings.py里确认三个配置：

STATIC_URL = '/static/' STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles') MEDIA_URL = '/media/' MEDIA_ROOT = os.path.join(BASE_DIR, 'media')

开发模式下如果图片能通过http://127.0.0.1:8000/media/xxx.jpg访问，说明media配置没问题。如果404了，要在项目的urls.py里添加：

from django.conf import settings from django.conf.urls.static import static urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

模拟生产环境部署时，很多人会忘记执行python manage.py collectstatic，导致打开页面后CSS全部404。这一步不能省，它会把所有app的静态文件统一收集到STATIC_ROOT目录里，nginx才能正确接管。

6. 项目答辩与论文写作建议

6.1 论文结构怎么组织

论文结构建议完整但不必过度堆砌，核心章节可以这样组织：

第一章绪论，写背景和意义，以及国内外研究现状，这部分要引用一些文献
第二章相关技术介绍，写python、django、mysql、深度学习、YOLO算法的原理
第三章需求分析，写功能需求和非功能需求
第四章系统设计，写总体架构、功能模块设计、数据库设计
第五章系统实现，写每个模块的实现代码和效果截图
第六章系统测试，写测试用例和测试结果
最后是总结与展望

技术介绍部分不用写太深，但要准确。YOLO算法的原理，至少要讲清楚“把目标检测当作回归问题，用一个卷积神经网络同时预测目标的类别和边界框”这一核心思想，然后举一个它的结构图。

6.2 答辩高频问题与应对

答辩时评委老师最喜欢问的问题，提前准备好答案能让你信心倍增。

“为什么选择YOLO而不是其他目标检测算法？”这是一个必问题。答：YOLO相比Faster R-CNN，把检测速度做到了实时级别，更适合需要快速响应的应用场景；相比SSD，YOLO在小目标检测上有改进版本，而且社区生态好。

“你的系统有哪些创新点？”这是一个关键问题。可以答：系统把深度学习和web技术结合起来，以实际应用为导向；检测结果可视化，用户能直观看到检测框和类别；支持历史数据统计，能完成垃圾类型分布分析。

“数据是从哪里来的？”诚实回答：使用公开的垃圾分类数据集，并对数据进行了预处理和数据增强。千万不要说有自己采集的千张图，评委追问起来会很尴尬。

6.3 系统的可扩展方向

如果你想让项目更有深度，可以在这几个方向做扩展：

换用YOLOv8或者更轻量的模型（如MobileNet-YOLO），比较不同模型的效果差异
加入摄像头实时检测功能，用OpenCV读取视频流，但注意django开发服务器不擅长处理长连接，可以引入WebSocket或者用轮询方式实现
增加检测报告的PDF导出功能，生成带统计图表的报告文件
把系统部署到云服务器上，使用docker容器化，将nginx+gunicorn+django+mysql整体打包，写一篇部署文档

这些扩展如果选一个在论文里实现，能为项目增色不少。我当时写的是加了一个垃圾地图分布功能，把检测到垃圾的地点（经度和纬度）标记在地图上，后来答辩的时候评委确实对这个功能问了很多细节。

7. 项目经验的复盘与总结

做这个系统前前后后大概花了两到三周时间。最耗时的反而是在环境配置和模型部署上，真正写业务代码的时间不超过一周。这段经历让我对深度学习落地到web应用有了不少实际感受。

第一，也是最重要的：环境隔离非常关键。推荐在项目一开始就建好Python虚拟环境，把依赖都固定到requirements.txt里。如果环境变量、python版本、CUDA版本之间互相干扰，排查起来特别费时间。有同学就是因为在系统python环境里反复装卸torch，最后把整个环境搞坏了，重装了系统。

第二，深度学习模型的性能优化空间比想象中大。模型第一次加载时间很长，但加载完之后的推理速度其实很快。在实际测试中，CPU上单张图片的推理时间大约在500毫秒以内，对单用户的毕设系统来说完全足够。内存占用是更需要注意的指标，一个YOLOv5s模型加载后大约占用1-2GB内存，如果后台进程一多就很容易超内存。

第三，日志和异常处理一定要做完整。在实际运行过程中，图片格式不对、图片损坏、模型推理出错，这些都是可能发生的。如果你没有做异常捕获和日志记录，出了问题只能干瞪眼。我后来给每个关键步骤都加了try-except，并把错误信息写入日志文件，排查问题就顺手多了。

最后再分享一个小技巧：在答辩演示时，提前准备一个专门的测试图片集，包含不同场景（白天、夜间、近距离、远距离、多种垃圾混合）的路面照片，演示时按顺序上传，既能把系统功能展示得全面，也不会在会场因为网络不好或者图片不合适而出错。这些准备虽然是细枝末节，但往往决定了答辩现场的流畅度。

本文还有配套的精品资源，点击获取

路面垃圾检测系统：Django+MySQL+YOLO深度学习实战解析