基于YOLOv5的车辆违停识别告警系统：Python毕设项目解析

简介：本资源是一套面向计算机相关专业本科生与研究生的毕业设计级车辆违停智能识别系统，基于YOLOv5深度学习框架实现，解决城市交通管理中静态违停行为的自动检测与实时告警问题，适用于毕设、课程设计及AI视觉项目实践。压缩包共217个文件，含48个Python源码（含GUI主程序、背景提取、模型推理等核心模块）、47个YAML配置文件（含数据集定义与训练超参）、45张PNG评估曲线图（如PR曲线、F1-score变化趋势）、26张JPG测试样本及3个预训练.pt模型，整体大小为181.12MB。已有436人学习下载，资源经实测可直接运行，提供完整环境配置方案（Python 3.8+Anaconda+PyCharm）、自定义违停区域标注方法、多源输入支持（本地视频/USB摄像头/RTSP流）及三类车型（car/bus/truck）高精度检测能力，配套Dockerfile与.gitignore等工程化文件，便于二次开发与部署。

1. 项目概述与系统定位

1.1 这个毕设项目到底在解决什么问题

车辆违停识别检测告警系统，说白了就是让计算机代替人眼去盯监控画面，自动发现哪些车停在了不该停的地方，然后立刻发出告警。城市里机动车保有量持续增长，违停成了交通管理里最头疼的问题之一，过去靠人工巡查或者看监控回放，效率低不说，还容易漏看。把这个过程自动化，就是这套系统存在的核心价值。

我刚拿到这个标题的时候，第一反应是它把整个毕设的交付物列得很清楚——Python源码、训练好的模型、GUI界面、评估指标曲线，而且还标注了"包含模型"和"包运行"，说明作者不只是交了一份理论报告，而是真正跑通了一套可演示的系统。对于本科毕设或者研究生课设来说，这已经属于"完成度相当高"的范畴了。因为很多学生做到最后，模型能跑出来就已经烧高香了，能再套一个图形界面让人实际操作，已经是很加分的呈现方式了。

从技术栈来看，这个项目覆盖了计算机视觉的完整闭环：数据采集与标注、模型训练、推理检测、业务逻辑判断、告警输出、可视化展示。也就是说，你做完这个项目，相当于把深度学习落地的整个流程都走了一遍。这对后面找算法岗实习或者做实操项目，都是很好的经历背书。

1.2 适用人群与实际应用场景

如果你是以下这几类人，这套系统的思路和代码是值得仔细研究的：

• 计算机、软件工程、人工智能方向的本科生，正在做毕设或者课程设计，需要一个既有技术深度又有演示效果的题目；
• 研究生想快速上手"目标检测 + 业务逻辑"的完整项目，作为科研方向的先导实验；
• 想转型做CV（计算机视觉）方向的开发者，需要一个能放进简历、能在面试时讲清楚细节的项目。

应用场景方面，这套系统能延伸的地方其实挺多的：

• 城市道路违停监测：对接路边摄像头或球机，自动识别禁停区域内的违停车辆；
• 小区消防通道占用告警：消防通道被占是老大难问题，用视觉方式自动识别并推送告警，物业能在第一时间介入；
• 停车场出入口和内部管理：识别违规占位、逆向停车等情况；
• 重点单位周边管控：学校、医院门口常常因为临时停车导致拥堵，系统可以辅助管理人员快速响应。

这里要多说一句，很多同学做项目时容易陷入"我只做一个模型训练"的误区，导致最后答辩的时候只有一个Jupyter Notebook的记录和几张loss曲线图。这个项目聪明的地方在于：它把"违停识别"这个业务问题拆成了"检测模型 + 规则判断 + 告警展示"三个层次。检测模型只负责找出画面里的车，而"是否违停"这个结论是由业务规则来定的——比如车位线外停车超过一定时间、禁停区域出现车辆停留等。这种设计思路非常关键，因为纯靠模型去直接判断"违停"既困难又不稳定，而"检测 + 规则"的组合在工程上才是真正可落地的方案。

2. 核心技术与模型选型解析

2.1 为什么目标检测是违停识别的最佳切入点

车辆违停识别的问题本质上是"在图像中定位车辆位置，再结合位置信息判断是否违停"。所以第一步一定是目标检测，而不是图像分类或者语义分割。分类只能告诉你"图里有没有车"，没法告诉你在哪个位置；语义分割能告诉你在像素级别哪些地方是车，但计算成本高，实时性差，而且对后续"判断是否停在禁停区"这个需求来说，提供的信息已经超出了需要。目标检测给出的边界框（bounding box）信息——中心点坐标、宽度、高度——恰好够用，又最省事。

这个项目的检测部分，选择了深度学习方案，而不是传统的图像处理方法（如背景差分、边缘检测、颜色分割等），原因很直接：传统方法对光照变化、阴影、遮挡、天气等因素极其敏感，稍微换个环境就不稳定。深度学习目标检测在复杂场景下的泛化能力明显更强，而且现在有大量预训练模型可以迁移学习，不需要从零训练。

从网络热词里能看到"yolov5"相关的搜索热度一直很高，这绝不是偶然。YOLO系列（You Only Look Once，只看一次）是目前工业界应用最广泛的目标检测框架之一，它的核心优势在于"单阶段检测"，也就是一次前向传播同时完成目标的定位和分类，速度和精度兼顾。尤其是YOLOv5在工程上的成熟度非常高，有极其丰富的社区资源和成熟的部署方案，Python直接调用权重文件就能用，非常适合作为这种毕设项目的检测底座。

当然，如果有同学想用Faster R-CNN或者SSD也完全可行，只是训练成本会更高或者精度可能不如YOLO。我在实际项目里的经验是：在通用的车辆检测任务上，YOLOv5和YOLOv8的默认权重（COCO预训练模型）可以直接检测出car、bus、truck这三类，不需要重新训练就能达到不错的检测效果。这就意味着，哪怕你手上没有自己标注的数据集，项目也能先跑起来，后续再用业务数据微调进一步提升精度。

2.2 检测模型训练与微调的完整思路

标题里说了包含模型，那这个模型是怎么来的呢？我拆解一下整个流程。

第一步，数据集准备。如果你有真实的监控画面数据，那是最好的，但大多数学生拿不到真实的道路监控视频，所以常见的做法是使用公开数据集做预训练，再用少量自己采集的图片做微调。公开数据集方面，UA-DETRAC、BDD100K、KITTI这些都有大量的车辆标注，COCO数据集本身就包含车辆类别。这里有个实操细节：COCO数据集里车辆被分成了car、bus、truck、motorcycle等多个类别，如果你只关心"机动车"这一个大类，可以在数据加载时做一个类别合并，把所有车辆类别的ID统一映射成同一个类别，这样模型的学习目标更集中，检测效果往往更好。

第二步，模型结构选择。如果你用的是YOLOv5，它提供了n/s/m/l/x五种不同规模的模型。选型原则是：毕设项目用YOLOv5s就足够了，它在COCO上有了不错的精度和速度平衡，在普通的GTX 1660或者RTX 3060显卡上都能跑得动。如果追求更高精度且不差推理时间，可以上YOLOv5m。我见过不少同学一上来就是用最大的YOLOv5x，结果训练时间翻倍不说，推理帧率还上不去，最后演示的时候反而卡顿。这个教训就是：模型的复杂度要跟你的算力匹配，不是越大的模型越好。

第三步，训练参数调优。关键的几个超参数包括：

• img-size：输入图片尺寸，YOLOv5默认是640x640。画面中车辆较小的话可以适当提高到960甚至1280，但代价是训练和推理变慢；
• batch-size：取决于显存大小，8到16是比较常见的设置；
• epochs：几百张图片的小数据集，100到200轮就足够了，再多容易过拟合；
• lr：初始学习率一般设置在0.001到0.01之间，配合余弦退火调度器；
• 数据增强：YOLOv5默认带了马赛克增强、随机仿射变换、HSV色彩空间扰动等，这些对小数据集特别管用，能有效提升模型的鲁棒性。

我个人的实操习惯是：先用默认参数训练50个epoch，观察loss曲线是否正常下降，再根据结果决定是继续训练还是调整参数。很多同学上来直接跑300个epoch，跑完发现loss震荡得厉害，其实早停（Early Stopping）或者中途调整学习率就能解决。

2.3 评估指标怎么看：不只是看准确率

标题里特意提到了"评估指标曲线"，这说明了作者对模型评价的重视。在目标检测任务中，光看准确率（Accuracy）是远远不够的，因为检测问题天然存在类别不平衡（图像中大部分区域是背景，车辆只占小部分）。最常用的评估指标是mAP（mean Average Precision，平均精度均值）系列。

具体来说：

• Precision（精确率）：检测出的目标有多少比例是真正车辆，高精确率意味着误报少；
• Recall（召回率）：所有真实车辆中有多少比例被检测出来了，高召回率意味着漏检少；
• AP（Average Precision）：以召回率为横轴、精确率为纵轴绘制PR曲线，曲线下的面积就是AP，它综合了不同置信度阈值下的表现；
• mAP@0.5：IOU阈值取0.5时的AP，这是最常用的评价标准；
• mAP@0.5:0.95：这是COCO的标准评价方式，IOU从0.5到0.95以0.05为步长取平均，更能反映检测框的回归精度。

在训练过程中，YOLOv5会实时输出每一轮的mAP值，最终呈现在results.png里。这里要提醒大家：不要只看最终mAP值，还要看曲线是否收敛、PR曲线的形状是否健康。如果precision高但recall低，说明模型偏保守，很多车没检出来；如果recall高但precision低，说明误报多——对违停检测这种场景，我一般会倾向提高精确率，因为误报告警比漏报更影响用户体验，容易让管理人员产生"狼来了"效应。

另一方面，损失函数曲线（box_loss、obj_loss、cls_loss）要呈现平滑下降的趋势，如果训练过程中loss反复震荡或者验证集loss持续上升而训练集loss下降，就是过拟合的信号了，需要加大数据增强或者降低模型复杂度。

3. 系统设计与实现细节

3.1 整体技术架构与模块划分

这套系统从架构上看是"算法层 + 业务层 + 展示层"的三层结构。这个分层思想是我很推崇的，因为很多毕设项目之所以一团糟，就是因为代码全挤在一起，训练代码、处理逻辑、界面代码混在几个文件里，最后想改一个功能都不知道从哪下手。

从架构层面来看，完全可以将其划分为以下模块：

1. 检测推理模块：负责加载训练好的权重文件，对输入图像/视频流进行推理，输出车辆边界框列表、置信度、类别信息；
2. 违停判定模块：接收检测模块的输出，结合预设的违停规则（禁停区域坐标、停留时间阈值等）做判断，输出违停事件；
3. 告警模块：当判定为违停时，触发告警——保存现场截图、绘制检测框、弹出GUI告警提示，或者向指定接口推送消息；
4. GUI界面模块：基于PyQt5或Tkinter构建，提供视频加载、实时检测显示、告警记录查询、参数配置等功能；
5. 评估可视化模块：加载训练过程保存的日志和指标，绘制loss曲线、PR曲线、mAP曲线等。

这种模块化设计的最大好处是，每一块都能独立测试。比如检测模块单独跑一个脚本，对着测试图片打标签；判定模块单独写好测试用例，把模拟的检测结果喂进去看看判断逻辑是否正确。这样每一步都有明确的验证方式，debug效率很高。

3.2 违停判定逻辑的核心设计

车辆检测模型只负责回答"汽车在不在这个位置"，它不负责回答"停在这里算不算违停"。业务逻辑部分的规则设计反而是这个项目区别于普通目标检测项目的关键。

我在设计违停判定规则时，用到了这样几种思路，各有适用场景：

• 区域越界判定：在画面中手动划定禁停区域（多边形或者矩形），检测到车辆框与禁停区域的重叠面积超过一定比例（比如IOU大于0.5），就触发违停候选。这个方法最简单也最直观，适合固定机位的摄像头；
• 停车时长判定：单帧图像无法判断"停"和"临时上下客"的区别，所以必须结合视频帧序列，连续N帧检测到同一位置的车辆，说明它停留超过T秒，才判为违停。这需要简单的目标跟踪逻辑，比如基于边界框中心点的最近邻匹配，或者直接用DeepSORT框架进行跟踪；
• 车位占用规则：如果是车位管理场景，可以预先知道每个车位的位置和编号，画面上有车但不在车位线内，或者跨线停车，都算违停。

在毕设演示的时候，我建议至少实现"区域越界判定 + 停车时长判定"的组合，这样能从两个维度展示系统的能力：既能理解空间规则，又能理解时间规则。UI界面上最好能直观地画出禁停区域和检测框的位置关系，评审老师一眼就能看出逻辑是否合理。

车辆检测与车道线识别 - 百度AI - 知乎专栏

关于这个项目的一个比较核心的点是：违停判定的输出结果，我建议统一封装成标准格式，比如一个字典或者JSON对象，包含时间戳、车辆位置、车辆类别、置信度、判定理由（是停在禁停区还是超时停留）、抓拍图片路径等字段。这样做既方便GUI界面展示，也方便后续扩展成告警消息推送到手机端。

3.3 GUI界面设计与交互逻辑

标题里明确提到了GUI界面，说明这是项目的一个亮点。用Python做桌面GUI，主流选择有两个：Tkinter和PyQt5。

Tkinter是Python自带的库，优点是不用额外安装、上手简单，缺点是比较简陋，做出来的界面不太好看，而且处理视频流刷新这种高频操作时性能一般。

PyQt5是Qt的Python绑定，功能非常强大，控件丰富、样式现代、支持自定义信号与槽机制，特别适合做这种需要实时刷新视频画面、显示检测结果、支持按钮交互的应用。如果要在毕设答辩时现场演示，PyQt5做出来的界面观感会好很多。

GUI至少要包含这些功能区域：

1. 视频显示区：实时显示检测结果，画面中绘制检测框、置信度、类别标签，禁停区域用半透明色块标出；
2. 控制按钮区：加载视频文件、开启摄像头、开始检测、暂停检测、复位等；
3. 告警信息区：以表格或列表形式展示历史告警记录，包含时间、位置、处理状态（已处理/未处理）；
4. 状态栏：显示当前检测帧率、模型名称、是否处于告警状态等实时信息；
5. 参数设置区：设置置信度阈值、IOU阈值、违停时间阈值等。

技术实现上有几个需要注意的坑。第一个是视频流的读取和显示不能放在主线程，否则界面会卡死。正确做法是用QThread开启一个工作线程，专门负责视频帧读取和模型推理，处理完的结果通过信号（Signal）传给主线程更新界面。第二个是模型推理时间如果超过100毫秒，视频显示就会明显掉帧，可以通过调整帧率上限（比如每秒只处理10帧）或者缩小输入图像尺寸来解决。第三个是摄像头或者视频文件的资源释放，程序退出时要确保进程彻底停止，否则摄像头会被占用，下次打开会报错。

4. 实操过程与核心代码解析

4.1 环境配置与依赖安装

刚拿到这个zip包的时候，第一步肯定是解压看目录结构。一个合理的项目结构应该是这样的：

vehicle_violation_detection/ ├── weights/ # 存放训练好的模型权重 │ ├── yolov5s.pt │ └── best_violation.pt ├── dataset/ # 数据集文件 │ ├── images/ │ ├── labels/ │ └── data.yaml ├── detection/ # 核心检测模块 │ ├── detector.py │ └── config.py ├── violation/ # 违停判定模块 │ └── judge.py ├── gui/ # GUI界面模块 │ ├── main_window.py │ └── worker_thread.py ├── eval/ # 评估指标计算 │ ├── metrics.py │ └── plot_curves.py ├── utils/ # 通用工具函数 ├── requirements.txt └── README.md

环境依赖方面，Python版本建议3.8到3.10，因为很多深度学习框架对3.11以上版本的支持还不太稳定。核心依赖包包括：

• PyTorch：模型训练和推理的基石，CPU版本也能跑，但GPU版本速度快几倍到几十倍；
• OpenCV-Python：负责图像和视频的读写、基本预处理（缩放、颜色空间转换等）；
• PyQt5：GUI界面的实现；
• NumPy：数组和矩阵运算；
• Matplotlib：绘制评估指标曲线；
• PyYAML：读取数据集配置文件。

安装的时候建议用一个干净的虚拟环境，避免系统环境里各种包版本互相冲突。我在实际部署中遇到过很多次因为Numpy版本不对导致OpenCV导入报错的情况，或者PyTorch的CUDA版本与显卡驱动不匹配导致GPU无法使用。

4.2 核心检测代码的加载与推理

这部分是整个系统的最底层，直接决定了能不能在断电和网络异常（断网）的情况下正常运行。核心代码逻辑大概长这样：

import cv2 import torch import numpy as np class VehicleDetector: def __init__(self, weights_path="weights/best_violation.pt", conf_thres=0.45, iou_thres=0.5): # 选择运行设备 self.device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu") # 加载YOLOv5模型，这里直接用torch.hub加载本地权重 self.model = torch.hub.load("ultralytics/yolov5", "custom", path=weights_path, force_reload=False) self.model.conf = conf_thres self.model.iou = iou_thres self.model.to(self.device) def detect(self, frame): # 输入是BGR格式的numpy数组，YOLOv5内部会做归一化和resize results = self.model(frame, size=640) # 转成pandas DataFrame或者numpy数组 detections = results.pandas().xyxy[0] # xmin,ymin,xmax,ymax,confidence,class,name boxes = [] for _, row in detections.iterrows(): boxes.append({ "bbox": [row["xmin"], row["ymin"], row["xmax"], row["ymax"]], "conf": row["confidence"], "cls": row["name"] }) return boxes, results

这里有个重要的经验要注意，torch.hub.load("ultralytics/yolov5", ...)这个写法会自动从GitHub下载YOLOv5的源码仓库，如果你的网络环境不太好，这一步可能会失败。解决方案是提前把YOLOv5的源码clone到本地，然后：

self.model = torch.hub.load("本地路径", "custom", path=weights_path, source="local")

或者干脆直接用YOLOv5的detect.py脚本作为外部工具调用，通过它的命令行参数传入权重和视频路径。虽然这种方式不够优雅，但胜在稳定，毕设阶段完全够用。

4.3 违停判定与告警逻辑实现

违停判定的逻辑我拆成两步来实现。第一步是"车辆是否出现在禁止区域"，第二步是"是否持续停留超过设定时间"。

import time import cv2 from shapely.geometry import Polygon, box as Box class ViolationJudge: def __init__(self, forbidden_region, min_stay_seconds=5): # forbidden_region比如是[(100,200),(300,200),(300,400),(100,400)]这样的顶点坐标 self.forbidden_polygon = Polygon(forbidden_region) self.min_stay_seconds = min_stay_seconds self.tracked_vehicles = {} # 用车辆中心点做简单跟踪 def check(self, detections, current_time): violations = [] for det in detections: bbox = det["bbox"] vehicle_box = Box(bbox[0], bbox[1], bbox[2], bbox[3]) # 判断与禁停区域的重叠面积 overlap = vehicle_box.intersection(self.forbidden_polygon).area if overlap > 0.3 * self.forbidden_polygon.area: center = ((bbox[0]+bbox[2])/2, (bbox[1]+bbox[3])/2) # 如果车辆之前没出现过，记录出现时间 # 如果出现过且持续时间超过阈值，记违停 ... return violations

这个逻辑本身不复杂，但有三个细节值得注意。

第一，IOU阈值不能设太高。车辆在画面中可能只有一部分伸进了禁停区域（比如卡车车尾压线），如果要求IOU大于0.5或者0.7才会被判为违停，可能会漏掉很多真实违停情况。我一般用"重叠面积占禁停区域面积的比例"或者"占到车辆框面积的比例"来衡量，两种口径各有适用场景。

第二，关于"停留时间"的判定，需要跨帧匹配。最简单的做法是记录每个车辆中心点的位置，如果新一帧出现一个中心点离某个旧记录小于一定像素阈值，就认为是同一辆车。这个方法在摄像头固定不动的前提下效果不错；摄像头如果有抖动或者场景背景复杂，建议直接用DeepSORT做目标跟踪。

第三，告警触发后要设置一个冷却时间（比如同一辆车30秒内只告警一次），避免系统反复触发导致告警风暴。这个在真实的监控场景中非常重要，我第一次部署时没有加冷却，结果一辆出租车在禁停区停了5分钟，系统告警了五十多次，管理人员直接把通知屏蔽了。

告警的输出形式除了GUI界面上的弹窗之外，我还会保存一张带检测框的现场截图，并附上一个包含时间、车辆坐标、类别等信息的文本文件，这样就有了完整的证据链。后续如果要做更完善的系统，可以在此基础上接入消息队列，把告警记录发送到微信或邮件，那就更像一个真正的商业产品了。

4.4 评估指标曲线的绘制方法

项目的最后一个核心交付物是评估指标曲线。我们生成曲线时，可以用训练过程中记录的信息，也可以用验证集重新评测。

使用训练过程中的结果文件是最直接的方式。YOLOv5在训练结束后，会在runs/train/exp目录下生成results.csv和results.png，里面包含了每一轮的box_loss、obj_loss、cls_loss、precision、recall、mAP@0.5等指标。直接用Matplotlib重新绘制一份更精细的图放在论文里，效果会好很多。

import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv("runs/train/exp/results.csv") epochs = df["epoch"] plt.figure(figsize=(10, 6)) plt.plot(epochs, df["metrics/precision"], label="Precision", linewidth=2) plt.plot(epochs, df["metrics/recall"], label="Recall", linewidth=2) plt.plot(epochs, df["metrics/mAP_0.5"], label="mAP@0.5", linewidth=2) plt.plot(epochs, df["metrics/mAP_0.5:0.95"], label="mAP@0.5:0.95", linewidth=2) plt.xlabel("Epoch") plt.ylabel("Metric") plt.title("Training Metrics Curves") plt.legend() plt.grid(True) plt.savefig("eval/metrics_curves.png", dpi=200)

另外还应该画一个PR曲线（Precision-Recall Curve），这个能直观反映模型在不同置信度阈值下的综合表现。YOLOv5的验证代码本身会在results目录下生成PR曲线图，如果没有，可以自己用验证集计算每个类别的PR值再绘制。

这里要特别说一个我在做评估时常被问到的点：单一指标的可信度问题。如果你的模型是自己在小数据集上微调的，mAP值看着不错，但实际视频里表现却不太好，常见的原因是训练集和测试集分布不一致，比如训练图全是白天光线良好的场景，测试视频里却有傍晚光线很暗的场景。所以评估指标曲线只能说明模型在特定测试集上的表现，不代表真实环境的效果。最好的做法是留出一段完全没有参与训练的"真实场景"视频，人工看一眼检测效果，再结合指标综合评价。

5. 常见问题与避坑指南

5.1 环境部署和运行阶段的高频问题

我帮不少同学看过类似的毕设项目，环境部署这里踩的坑是最多的，而且很多问题看起来匪夷所思，实际上原因很简单。

第一个高频问题：运行时报ModuleNotFoundError: No module named 'torch'。这种情况100%是当前环境不是你装PyTorch的那个环境。很多人用Anaconda创建了多个虚拟环境，但在PyCharm或者命令行里没切换对。解决办法是先看当前环境里有哪些包：

conda env list conda activate your_env_name python -c "import torch; print(torch.__version__)"

如果输出的是CUDA版本（如2.0.1+cu118），说明GPU版生效。

第二个高频问题：cv2.error: OpenCV(4.x) ...。这类错误通常和图像尺寸或者数据类型有关。比如YOLOv5要求输入是HWC顺序、BGR通道、UInt8类型，如果你用别的库（比如PIL）读图，RGB顺序会导致颜色混乱但一般不会报错；如果输入的数据类型变成了float64，OpenCV的某些函数就会直接抛异常。解决思路是统一用cv2读取，再转成RGB（如果需要显示的话）。

第三个高频问题：GUI界面打开就崩溃或者黑屏。多半是QThread和主线程交互没有处理好，在子线程里直接操作了主线程的控件。解决方式是用信号与槽机制，在子线程里emit信号，主线程里接收信号再更新控件。

第四个高频问题：GPU显存不足（CUDA out of memory）。这不一定是你显卡太小，有时候是其他程序占用了显存。可以用nvidia-smi查看，如果有僵尸进程占用，直接kill掉。如果确实是显存不够，就把batch-size调小、输入图像尺寸从640降到480，或者推理时加上torch.no_grad()，再把每次推理产生的中间变量显式释放。

这里整理了一个快速排查表：

5.2 模型效果相关的排查与优化方法

如果你的系统已经能跑起来，但检测效果不如预期，这里有几个实用的调优方向。

一是数据问题优先于模型问题。模型误检或者漏检严重时，先看测试图片本身：是不是车辆占比太小？是不是画面太暗？是不是存在大量遮挡？如果车辆占比小，可以增加输入分辨率；如果光线暗，可以加一个自适应直方图均衡化的预处理步骤。绝大多数"模型效果差"的问题，其实都是数据分布和预处理策略的问题，跟模型结构关系不大。

二是过拟合和欠拟合的区分。训练集loss很低但验证集loss高，就是过拟合：减少训练轮数、增加数据增强、加入Dropout或者权重衰减。两个loss都高且不下降，就是欠拟合：有可能是学习率设置不当，或者模型太小，可以增大学习率、换更大的模型。

三是类别不平衡的问题。如果你的数据里轿车的数量远多于卡车和公交车，模型对后两类车辆的召回率会偏低。解决办法是使用类别权重损失、随机过采样少数类，或者在最简单的情况下，多收集一些少数类的样本。

我在这个项目里遇到过的最头疼的问题是：模型对"电动车"和"摩托车"的误检，导致很多非机动车也被当作"车辆违停"。排查下来发现，是因为很多训练样本里电动车的形态和摩托车太接近了，模型无法有效区分。解决方法是把类别合并成"vehicle"一个大类，只做车辆检测，再把"是否违停"完全交给业务规则去判断。这个改动带来的收益非常明显，误检率大幅下降。这也是我反复强调"检测 + 规则"分离设计的重要原因——检测的错误可以通过业务逻辑来兜底，但前提是你别让检测模型承担太多它不该承担的判断任务。

5.3 演示和答辩环节的准备工作

既然是毕设项目，最终效果很大程度上取决于现场演示是否顺利。我在几个同学答辩前帮忙把关的时候，总结出一些非常实际的经验：

• 提前录好一段演示视频作为备用方案。现场如果GPU驱动出问题、摄像头坏了、网络断了，至少能播放录好的视频，不至于完全冷场；
• 演示视频不要选太长的，30到60秒就够了，但要包含一个从"正常"到"违停"再到"告警"的完整事件链；
• 界面上能直观看到检测框、置信度、禁停区标识、告警记录列表，这些关键元素要在第一屏就能被看到，不要藏在二级菜单里；
• 准备3到5张效果较好的检测结果图，放到论文或者PPT里，作为定性展示；把mAP曲线、PR曲线作为定量展示。

答辩时可能被问到的高频问题也提前想想：为什么选YOLOv5而不是其他模型？数据从哪来、怎么标注？违停判定的规则是什么、阈值怎么定的？系统实时性如何、帧率是多少？这些问题在本文里都已经覆盖到了，能讲清楚其中六成，项目答辩的基本盘就很稳了。

6. 项目扩展方向与个人体会

6.1 从毕设到可落地产物的进化路径

这个项目的底子是很好的，如果后续还想继续完善，有几个扩展方向值得考虑。

第一个方向是接入真实视频流。目前系统大概率是处理本地视频文件或者摄像头画面，可以扩展成直接拉取RTSP视频流，对接市面上主流的网络摄像头和监控平台。这会让系统的实用性提升一个层级。

第二个方向是增加端侧部署能力。目前模型跑在PC上，用PyTorch推理。如果要在边缘计算设备（比如Jetson Nano、树莓派）上运行，需要把模型导出为ONNX或者TensorRT格式，推理速度能提升好几倍。这个对就业和项目落地会很有吸引力。

第三个方向是性能数据化。当前版本可能只统计了模型指标，但没有统计系统运行指标，比如告警响应时间、检测平均耗时、CPU和内存占用。补上这部分数据，论文里就有了更完整的技术评估维度。

第四个方向是完善告警后处理流程。比如告警记录自动同步到云端数据库、支持按时间查询历史记录、生成每周违停统计分析报告等。这些功能虽然不算核心算法，但能显著提升系统的完整度和用户友好度。

6.2 我在复现和调试这个项目过程中的一些心得体会

这个项目涉及深度学习、图像处理、GUI开发、软件开发等多个方向，是一次非常典型的"全栈"综合性项目实践。在做完整个流程之后，我最大的体会是：深度学习项目的关键不在于模型有多新、参数有多大，而在于"系统能不能稳定运行、效果能不能直观展示、逻辑能不能自圆其说"。很多同学在模型选型上纠结很久，其实不如先把一个成熟方案跑通，再逐步调优来得实在。

另一个体会是关于"技术深度"和"业务理解"的关系。我见过不少项目，模型的mAP刷得很高，但完全没考虑实际业务场景里的问题——比如摄像头角度带来的透视畸变、白天和夜晚的光照差异、禁停区域被树木遮挡等。真正有工程价值的系统，一定是在理解业务的基础上做算法选型和逻辑设计的。违停检测这个需求看起来挺简单，但"怎么定义违停"、"告警之后怎么办"这些业务问题，每一个背后都有不少坑。

最后分享一个小技巧：在整个项目开发过程中，尽量养成写实验记录的习惯。每次训练跑了多少个epoch、用了什么数据增强、最终mAP是多少、踩了什么坑，都记在一个实验日志文件里。到了写论文或者技术博客的时候，这些记录就是最宝贵的素材。我现在回头看自己一两个月前做的实验，很多细节如果没有记录，早就忘得一干二净了。

这个项目本身并不复杂，它最大的价值在于把一堆独立的算法组件组装成了一个能解决真实问题的系统。如果你也是正在为毕设发愁的同学，希望这篇拆解能帮你理清思路。技术选型上有不同的偏好很正常，但"检测 + 规则 + 展示"的这套系统化思维，我觉得任何时候都是值得借鉴的。

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