简介：这份基于YOLOv8的旅游景区人流预警系统，是一套面向计算机相关专业毕业设计或课程设计的完整工程包，覆盖目标检测、模型训练评估与可视化展示全流程。项目代码已实测运行通过，适合计科、人工智能、通信、自动化等专业学生快速搭建演示系统，也可作为企业员工或初级学习者的实战参考。压缩包共97个文件，以70个Python脚本为主体（含主程序、检测服务与工具模块），另包含12个编译缓存pyc、5个xml配置文件、4个pt模型权重（含yolov8n.pt与训练得到的best.pt）、训练说明txt及操作演示mp4等，总大小仅24.21MB，结构清晰，下载后按说明即可部署。资源除源码和数据集外，还提供可视化主界面与部署教程，能自动产出核心指标曲线、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图，方便直接用于答辩展示或中期汇报。目前已有41人学习下载，适合作为毕设保底方案或目标检测入门项目二次开发。

1. 别把景区人流预警做成“数人头游戏”：为什么这个项目值得照着做

如果你对着景区监控画面做过目标检测，第一反应肯定是“用YOLO框出人来不就行了”。但真正把“基于YOLOv8的旅游景区人流预警系统”跑起来之后你会发现，难点从来不在检测框画得准不准，而在于三个很实际的问题：同一行人跨帧重复计数怎么去重、人头在俯视视角下被严重遮挡怎么保住召回、所谓“预警”到底是按人数阈值报警还是按单位面积密度来算。这套系统打包了源码、可视化界面、完整数据集和部署教程，本质上是一个“目标检测 + 业务规则 + 界面工程”的完整工程样本，适合正在做CV方向毕设或课设的学生，也适合想给园区的视频监控加一档人流密度评估能力的从业者。

我接触过不少同类作业，最容易翻车的不是模型训练，而是“直接把人头数当预警依据”，根本扛不住摄像头视角变化和观光车、商铺人流等干扰。这个标题的价值在于它把预警当成一条完整链路来设计：采集、推理、统计、可视化、分级告警。这篇笔记就按这个链路拆开讲，先说明白YOLOv8哪些特性适合做人流密集场景，再逐步落到数据集处理、训练参数、界面联动和部署避坑。

2. YOLOv8核心特性与系统整体设计：先搞懂检测器，再动界面

2.1 yolov8网络结构的三个关键变化：C2f、Anchor-Free和解耦头

YOLOv8相比YOLOv5，最影响人流场景的改动是这三处。第一是骨干网络的C2f模块，它把原来的Bottleneck串行结构改成多分支并行，再用concat合并，特征图的信息更丰富。对应到人流密集的场景，行人之间互相遮挡时，局部纹理和边缘响应对检测头更重要，C2f这种多尺度特征的传递方式能减少小目标的响应衰减。第二是Anchor-Free，模型不再依赖预定义锚框，而是直接预测目标中心点和宽高。景区摄像头大多是高杆俯视，人形尺度跨度很大，个体之间尺度差异能到10倍以上，Anchor-Free在小尺度目标上不需要调锚框比例，省了不少调参的玄学时间。第三是解耦检测头，分类和回归分支分离，收敛速度比耦合头快很多，训练初期loss下降不稳定时更容易判断是数据问题还是模型问题。

这套项目的训练代码一般直接基于Ultralytics官方工程，你可以从yolov8网络结构图里看到Detect头输出了三个不同尺度的特征层，分别负责大中小目标。对于人流密度场景，中尺度和大尺度输出差异不大，真正决定效果的是小目标层在20×20到40×40之间的响应是否足够。5个模型的对比参数也决定了你该怎么选择权重。

我一般会建议毕设直接选s起步，不要一上来就用x。原因不是显存不够，而是景区人流视频通常很大，x模型推理耗时是s的三到四倍，界面刷新率低于5帧时，后面的预警逻辑再好也体现不出来。如果你看到的源码包默认加载的是yolov5s.pt或者yolov8s.pt，那也验证了这个选型思路。

2.2 系统整体数据流与模块划分：从视频流到预警灯

这套系统的核心数据流可以拆成五条链路：视频采集、目标检测、密度统计、分级预警、可视化展示。视频采集端支持三种常见来源：本地mp4文件、RTSP摄像头流和图片目录。检测端加载训练好的YOLOv8权重，输出每个目标的类别、置信度和边界框。密度统计端需要结合区域信息计算，也就是预先在界面上画好ROI多边形，系统只统计落在多边形内的人数，用人数除以多边形对应的实际面积得到密度值。分级预警端按密度阈值与人数变化趋势触发不同等级提醒。可视化端要承担三件事：实时画面标注、密度热力图渲染、预警状态文字提示。

模块之间建议用生产者消费者模型解耦，否则界面刷新会拖垮推理线程。采集线程向队列写帧，推理线程从队列读帧并调用模型，界面线程定时拉取最新结果。这个架构对毕设来说已经足够，代码量不大，但能避免一个很典型的问题——界面卡死时连带着摄像头拉流也跟着崩溃，这在OpenCV直连的单线程写法里很常见。

2.3 为什么不在这个系统里直接用人体检测做计数

很多人拿到的毕设源码里，模型训练用的标签不是“人”，而是“人头”。这在一开始看起来很反直觉，但实际跑一段景区俯视视频就明白了：相邻游客的肩部往往互相重叠，人体检测框之间大量重叠，NMS被挤爆，最终检测框数量还不到实际人数的一半；而人头在俯视图下的形态独立得多，虽然像素面积小，但边界更清晰，检测头学起来更容易。如果你拿到手的数据集标签里是“person”，最好克制住直接训练的冲动，先看标注图像是平视还是俯视。平视镜头下person可以用，高杆机位下建议重新标注head类或改用标注了head的数据集。

3. 把数据集准备和模型训练变成可复现流程

3.1 数据集准备：LabelMe标注转YOLO格式的脚本与四个边界坑

这个项目里给你准备的数据集大概率是两种情况：一种是完整的images和labels目录，另一种是原始图片加LabelMe或LabelImg导出的json/pascal格式文件。如果是LabelMe标注，就必须做转换。YOLO格式的标签内容很简单，每行五个数：类别id、归一化后的中心点x、中心点y、框宽、框高，数值都在0到1之间。转换脚本我一般这样写：

import json import os from pathlib import Path def labelme_to_yolo(json_path, img_w, img_h, class_dict, out_txt_path): with open(json_path, 'r', encoding='utf-8') as f: data = json.load(f) lines = [] for shape in data['shapes']: # LabelMe导出的points是多边形坐标，需要转成外接矩形 label = shape['label'] if label not in class_dict: continue points = shape['points'] xs = [p[0] for p in points] ys = [p[1] for p in points] x_min, x_max = min(xs), max(xs) y_min, y_max = min(ys), max(ys) # 归一化到0~1，防止越界 cx = ((x_min + x_max) / 2) / img_w cy = ((y_min + y_max) / 2) / img_h w = (x_max - x_min) / img_w h = (y_max - y_min) / img_h # 过滤掉过小和越界框：这类标注通常是人头边缘没画好，留着只会干扰训练 if w <= 0.01 or h <= 0.01 or cx > 1 or cy > 1: continue lines.append(f"{class_dict[label]} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}") with open(out_txt_path, 'w') as f: f.write("\n".join(lines))

转换脚本里的几个参数值得留意。img_w和img_h必须是图片解码后的实际像素，不能拿文件名直觉猜，不同来源的图尺寸不一致时最容易在这里翻车。class_dict的顺序就是最终训练的类别id，改标签名后必须和data.yaml里的names保持一致，否则会出现“检测到了人但显示成椅子”的诡异错位。过滤w <= 0.01是必要的，因为LabelMe里经常有人手滑点出一个只有几个像素的小点，YOLO训练时这些噪声框会让损失函数来回震荡。

转换成YOLO格式后，不要急着训练，先做一次可视化验证。常见做法是用OpenCV把标注框画在图上，肉眼抽查20张图。这一步能发现很多标签生成时的隐患，比如多边形顶点顺序错乱导致外接矩形过大、类别名和yaml不匹配导致所有框都归到id 0。我见过太多人直接训练后才发现数据质量差，白白浪费了一个通宵的GPU时间，这属于完全可以用两分钟脚本避开的坑。

3.2 训练自己的数据集：参数含义与损失曲线判读

数据准备好之后，训练命令可以基于Ultralytics的CLI，也可以直接跑官方train.py。最小可运行命令是：

yolo detect train \ model=yolov8s.pt \ data=dataset.yaml \ epochs=100 \ batch=16 \ imgsz=640 \ workers=4 \ device=0

# 如果只想用CPU实验，把device改成cpu，同时调小batch yolo detect train \ model=yolov8s.pt \ data=dataset.yaml \ epochs=20 \ batch=8 \ imgsz=640 \ workers=2 \ device=cpu

这里model=yolov8s.pt是加载预训练权重做迁移学习，而不是从随机权重开始，对毕设的数据量至关重要。batch要根据显存调整，8G显存跑s模型配到16没问题，但如果你还开着浏览器录屏，显存会被吃满导致训练直接OOM。imgsz在景区人头上尽量用640以上，如果检测框大多数小于32×32像素，直接提到1280会更有效果，代价是显存和训练时间成倍增加。

训练过程中最需要关注的是损失曲线和精度曲线的走向。Ultralytics在训练结束后会自动生成results.png，包含train/box_loss、train/cls_loss、metrics/precision等曲线。看曲线时不要只看loss降没降，要对比val曲线是否持续下降。如果val/loss下降但val精度停滞，说明模型过拟合或标签噪声较大，可以考虑增加数据增强、加大weight_decay，但最优先的是检查标签框是否把小目标框得不准。对毕设来说，训练到last.pt和best.pt后，只用best.pt做推理，不用纠结为什么最后一个epoch的权重效果反而变差，那是因为last有验证集上的性能波动。

3.3 人头类别设置与数据增强的取舍

如果你使用的是标题里自带的完整数据集，类别通常是单类head，data.yaml怎么写没有太大争议。但如果要自己混入公共数据集如SCUT-HEAD或CrowdHuman，就要注意类别映射不能暴力合并。不同数据集对“头”的标注边界不同，有的标注包含头发，有的包含脖颈，混在一起会让模型学出一种“薛定谔的头部边界”。我建议一个场景一个数据集单独训，实在要混，先把两种标注统一成同一规则再合并。

数据增强方面，Ultralytics默认开启hsv_h=0.015、degrees=0.0、flipud=0.0。景区监控多半是固定机位，degrees保持0就好，随机旋转90度后，人头的朝向模式和俯视特征都会出现奇怪变化。flipud默认是0，千万不要随手调成0.5，因为俯视视角下翻转上下意味着把地面的影子、背包当成目标区域，模型训练出的特征会变成“凡是密集纹理都像头”。如果夜间场景多，hsv_h可以略微提高到0.02，但不要动饱和度和明度太多，否则白天和夜间的外观差异反而被拉大。

4. 可视化界面与预警逻辑：把检测结果变成可运营的指标

4.1 界面技术选型与线程分离：PyQt5和OpenCV怎么配合

可视化界面是整个系统中工作量最大的部分之一，也是最容易被答辩老师追问细节的地方。常见的做法是用PyQt5搭建面板，底层OpenCV负责绘图和视频解码，两者通过队列桥接。PyQt5用QGraphicsView展示画面，每一帧把YOLO推理的边界框画在一个QImage上，再传给人脸控件刷新。不要直接在paintEvent里做推理，那会让界面卡成逐帧慢放。

以下是一段最小界面刷新逻辑：

import cv2 import queue import sys from PyQt5 import QtCore, QtGui, QtWidgets class VideoThread(QtCore.QThread): frame_ready = QtCore.pyqtSignal(object) def __init__(self, src=0): super().__init__() self.cap = cv2.VideoCapture(src) self.running = True def run(self): while self.running: ok, frame = self.cap.read() if not ok: break # 到这里调用模型推理或者读取已推理结果的队列 self.frame_ready.emit(frame) QtCore.QThread.msleep(30) def stop(self): self.running = False self.cap.release()

这段代码的意义在于把视频拉流从UI线程里拆出去，msleep(30)控制帧率，避免CPU做推理时界面完全失去响应。生产代码里，推理结果应该由一个共享的results_queue传递，界面线程只负责取最新一帧结果画框，这样即便模型偶尔卡顿也不会让回放无响应。pyqt界面里的按钮、密度等级、预警灯状态，都通过Qt信号机制更新，比如检测线程发出alert_signal后，主线程刷新预警栏文字。

4.2 预警阈值体系：从人数阈值到单位面积密度的四级分级

预警逻辑的关键不只是“超过多少人报警”，而是“这个区域内单位面积承载了多少人”。景区的区域面积各不相同，如果只看人数，一个宽广场地和一个窄巷子用同一个阈值完全没有意义。常见做法是先让用户在界面上用鼠标画ROI多边形，系统计算该多边形的像素面积，再结合标定的每平方米像素数换算成实际面积。然后按四个人流密度等级输出：正常、关注、预警、危险。

阈值是直接写在配置项里的，不要在代码里硬编码。我一般习惯把density_normal_max、density_warn_max、density_danger_min做成ini或json配置，方便现场调，也能在毕设说明书里写“系统支持阈值可配置”。这个细节很多人容易忽略，写在论文里就是一个加分项，因为证明你不只是跑通了代码，还考虑了运营灵活性。

另外，预警不能只看瞬时密度，要加一个时间窗口的滑动统计。人流高峰可能在几秒内突然涌入，立刻报危险级会频繁误报。给预警逻辑加一个持续3到5帧的确认机制，只有当连续数帧超过同一阈值才真正触发提醒。这是景区环境中让我最受益的一个策略，否则观光车从画面边缘经过，热力图一下变红，值班人员会被假警报磨掉耐心。

4.3 用完整流程跑通项目：从入口到界面的最小步骤

拿到项目后，第一步是检查依赖版本，不要直接pip install ultralytics装最新版，已有的模型权重和界面代码大多是在某个版本上测试好的。先看requirements.txt里锁定的版本，如果缺失，装指定版本。第二步确认数据集路径。dataset.yaml里的path字段必须是实际目录，很多人因为移动到中文路径下训练时报错，看到Assertion: dataset not found就去改代码，其实只要改成绝对路径就好。第三步启动入口程序，通常是main.py或app.py：

python main.py --source test_video.mp4 --weights weights/best.pt --conf 0.35

运行后出现主窗口，可以看到视频画面、右侧信息栏和密度趋势图。到这里说明系统链路已经打通。如果弹窗一直黑屏，多半是视频路径不对或者codec不支持，优先尝试把这个视频在OpenCV里单独读取，判断是解码问题还是界面的问题。不要一上来就去改模型，很多所谓的“系统跑不起来”离模型远得很。

5. 部署避坑专题：从CPU到单卡GPU的五个翻车现场

5.1 现象一：CPU上推理速度只有0.3 FPS，界面跟幻灯片一样

原因不是YOLOv8慢，而是默认加载了yolov8x.pt加上没有启用半精度推理，还在每帧对原图全尺寸做预处理。解决方法是把模型权重换成yolov8s.pt或yolov8n.pt，推理时启用fp16，并把视频帧缩放后再进模型。多数毕设不需要每帧处理，设置每三帧检测一次、中间帧沿用上帧结果，肉眼完全无感知，但速度能提两倍以上。

import cv2 from ultralytics import YOLO model = YOLO("weights/best.pt") # 训练导出的best权重 cap = cv2.VideoCapture("test_video.mp4") frame_skip = 2 current_frame = 0 last_results = None while True: ok, frame = cap.read() if not ok: break if current_frame % frame_skip == 0: # 缩放到短边640再推理，速度比原始1920x1080快非常多 img = cv2.resize(frame, (640, int(frame.shape[0] * 640 / frame.shape[1]))) last_results = model.predict(img, half=True) current_frame += 1

这段代码里的frame_skip控制跳帧数，half=True开启FP16推理。注意half=True只在GPU环境有效，CPU上会落到float32。代码后的这些改动配合起来，目标就是保证演示流畅度，而不是堆精度。

5.2 现象二：夜间画面大量漏检，白天正常晚上翻车

原因很直接：数据集里几乎没有夜间样本，模型看到的画面和训练分布差异过大。解决思路不是重新收集海量夜间数据，而是先做预处理适配。把夜间帧的直方图均衡化后再送进模型，置信度普遍能提升。如果效果仍然不行，就要针对性地收集一段夜间视频标注并微调模型。不要寄希望于加一个gamma参数就能完美解决，光线变化对人头纹理的影响是本质性的。

5.3 现象三：一张密集人群图像有500多个标注框，训练时内存暴涨

原因是以大图原尺寸直接训练，模型上采样过程会撑爆显存。解决方法是先看图像的实际尺寸，如果每张图都在1920×1080以上，考虑裁剪成小块训练，比如从大图中滑窗切出640×640的patch，过滤掉目标过少的块再入训练集。这个策略本质上是SAHI的思路，适合密集小目标场景，比直接调大imgsz容易实现得多。

5.4 现象四：同一个人被反复计数，两个小时后人数爆表

原因是系统没有做帧间跟踪，每一帧的检测框都被当成新流入人员。解决方法是引入一个简单跟踪器，对检测框做IoU匹配，框位置在相邻帧移动小于阈值的视为同一人，维护一个人数ID列表。毕设里不需要端到端DeepSort，用OpenCV的tracker或ByteTrack库就够。每帧检测结果先过跟踪器，再根据跟踪到的目标中心判断是否在ROI内计数，这样只有“新出现的中心点”才会计数加一。

5.5 现象五：换rk3588或树莓派后模型部署跑不起来

这是边缘部署常见的坑：你训练的PyTorch权重直接在ARM设备上推理，速度完全不可用。针对rk3588这类设备，需要先把模型导出为ONNX，再转成RKNN格式，过程中要选量化方式。常见做法是量化感知训练，在训练阶段就模拟量化误差，转移后精度损失能控制在2%以内。另一个隐蔽问题是模型结构对量化不友好，比如某些激活层输出范围过大，量化后信息损失严重，这种情况下优先选择结构里带更多ReLU的变体，导出的RKNN稳定性明显更好。

6. 白天黑夜模型差异怎么验证：用最少的代价做出可靠的预警系统

系统做完后，不要直接拿一段白天的视频演示就当作完成。我习惯单独建一个validation_scenes目录，刻意放几个高难度片段，比如黄昏逆光、夜间路灯、阴雨天气下的景区入口。每次修改完模型或阈值后，用这个目录重跑一遍，观察不同场景下的准确率和漏检率变化，能让自己对系统边界有更真实的掌控。

验证的具体做法是做一个离线回归脚本。让系统读取验证视频并输出每帧的人数统计，然后和人工或已有数据的真实人数做对比。如果夜间场景准确率明显低于白天，优先检查置信度阈值，夜间整体置信度下降时，把阈值从0.5调到0.3会有显著改善。再进一步，可以统计预测人数和真实人数的相关系数，而不只是看单帧对错，这个指标写进毕设正文里会非常有说服力，也能体现你在评估上确实做了功课。

在进阶方向上，如果还想在校招或毕设加分，可以尝试把检测头换成轻量注意力版本的head，在原来C2f之后加一个SE注意力模块，专门增强低尺度特征图上的人头响应。对游客密度高的画面，这一个小改动往往能把召回率提升3到5个点。但要注意，改完网络结构后必须重新训练，不能用原来的训练日志声称效果，否则答辩时容易被追问细节。另一个更稳妥的改进是把二维人数统计扩展成区域间流向分析，统计从ROI A移动到ROI B的行人数量，这在景区出入口管控里很有价值，工作量却不大，只需要把跟踪ID的位置变化记录成轨迹即可。

最后留着我的一个习惯：每次跑通一个版本，就把模型的配置、数据集路径、关键阈值都存成一个experiment.json，连同训练日志一起归档。这样无论后来是换机器还是换数据，都能快速恢复到某个效果最好的版本。这套系统本身不难，难的是让它在不同光线、不同人流密度、不同摄像头高度下都保持稳定。希望这些踩坑经验能帮你在部署和展示的时候少走弯路，也希望你能在这个基础上做出自己的改进点。

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