先说明一下，我做农业相关的视觉项目有一阵子了。这个"基于YOLOv8的鸡检测和跟踪系统"看着像课设，实际上是个非常典型的"检测+跟踪+工程落地"三合一项目。如果你只打算跑个demo然后交差，那确实不难；但如果你想真正把鸡数清楚、跟得稳，甚至以后扩展到猪、牛、羊这些场景，里面值得抠的细节非常多。
这几年经常有朋友来问我，说"网上随便找个YOLOv8检测代码，一跑就通了，为什么一到自己的数据上就拉胯"。这其实不是YOLOv8的问题，而是大多数人没意识到：检测模型只负责"认出鸡"，跟踪要做的是"把同一只鸡从这一帧到下一帧连起来"，而UI界面又要解决"怎么把这两件事流畅地展示给人看"。三件事的难度是层层叠加的，任何一环偷懒，整个系统都会显得很"玩具"。
这篇文章我把整个项目的思路、数据、训练、跟踪、界面、部署全部拆开讲一遍，重点放在那些"网上教程不会细说、但你实操必然踩坑"的地方。
1. 项目整体设计与选型思路
1.1 为什么选YOLOv8而不是更早的版本或者其他模型
先说检测这块。YOLOv5其实到现在还有很多人在用，YOLOv8相对它最大的变化有几个：C2f模块替代了C3，能把梯度流做得更丰富；Head部分换成了解耦头，分类和回归分两条分支，收敛更快；另外数据增强和训练策略也内置得更完善。最直观的好处是，用ultralytics这个库跑YOLOv8基本不用自己写训练循环，一个model.train()就把整个流程包完了，特别适合做应用型项目。
在鸡这个场景上，YOLOv8的优势体现在小目标检测上。养殖场上摄像机一般架在高处，一只鸡在画面里可能只有二三十个像素宽，属于典型的小目标。YOLOv8的anchor-free设计在小目标上比YOLOv5的anchor-based更友好一些，虽然不是说碾压，但实测下来在同等算力下，v8的召回率通常会高几个点。
另外要提一句，项目标题里说"YOLOv8深度学习"——很多人以为深度学习部分是指标得自己搭网络，其实不是，YOLOv8已经是高度工程化的开源模型，我们真正动手的地方在于：数据集的构造、训练策略的选择、跟踪逻辑的串联，以及界面和底层检测之间的线程调度。把精力分配好，比纠结换哪个骨干网络重要得多。
1.2 跟踪器怎么选：ByteTrack和DeepSORT的取舍
跟踪是整个项目里最容易翻车的地方。YOLOv8自带的model.track()底层集成了ByteTrack和BoT-SORT，默认是ByteTrack。做过目标跟踪的都知道，DeepSORT需要为每个目标提取ReID特征，然后靠特征相似度做匹配，好处是抗遮挡能力强，坏处是特征提取非常吃算力，而且对特征模型本身的训练数据要求很高，你拿一个在行人数据集上训的ReID模型来跟鸡，效果多半是惨不忍睹。
ByteTrack的思路完全不同，它不提取外观特征，而是纯靠"高置信度检测框和低置信度检测框的关联"来做匹配。核心逻辑是：每一帧先做检测，得分高的框进第一次匹配，没匹配上的轨迹再尝试跟得分低的框关联，这样能捡回很多被遮挡或模糊的目标。对鸡这种外观千篇一律、遮挡又严重的场景，ByteTrack要比DeepSORT靠谱得多，而且速度快。
我实测过同一段鸡舍视频，DeepSORT在鸡群密集的时候ID切换频繁，一只鸡跟到一半变成另一只鸡的编号；换成ByteTrack以后，虽然偶尔还是会有切换，但稳定性明显提升。需要特别注意的是，model.track()默认要求传入的视频帧连续，如果你在UI里做抽帧或者跳帧，跟踪器内部卡尔曼滤波的预测就不准了。
1.3 UI界面和检测逻辑的层次划分
标题里写了"UI界面"，很多人会误解成"写个界面把视频流显示出来就行"。其实一个能用的界面至少要分三层：视频采集层、检测跟踪层、展示交互层。三层之间最好是解耦的，用队列或者信号槽传递数据，而不是把检测代码直接塞进界面的刷新函数里。
我见过不少同学的做法是：用一个QTimer定时器，每100毫秒抓一帧，同步跑一次YOLOv8推理，再把结果画到QLabel上。这样写在小视频上没问题，一旦换成实时摄像头流，界面会卡死，因为推理期间主线程被占用了，窗口无法响应鼠标事件。正确做法是开一个工作线程专门跑检测，结果通过信号发给主线程，主线程只负责画图。这块后面会专门细讲。
2. 环境搭建与依赖安装
2.1 版本匹配是最大的坑
YOLOv8的ultralytics包迭代速度很快，不同版本之间API差异不小。比如早期版本track()方法的参数是persist和conf，后来的版本又加了tracker参数用来指定配置文件。如果你抄了一个别人的代码，直接跑会出现"got an unexpected keyword argument"这种报错，大概率就是版本对不上。
我这边的环境组合是这样的，跑了很久没出过兼容问题：
| 组件 | 版本 | 备注 |
|---|---|---|
| Python | 3.10 | 3.9也行，别用3.13 |
| ultralytics | 8.2.x | 这个区间相对稳定 |
| PySide6 | 6.6.x | 做桌面UI |
| torch | 2.1.x | CUDA 12.1对应版本 |
| opencv-python | 4.9.x | 视频流读取用 |
| bytecode | 无特殊要求 | 跟torch兼容即可 |
安装指令就一行，但建议用国内镜像源，否则下载速度会让人崩溃：
pip install ultralytics PySide6 opencv-python -i https://pypi.tuna.tsinghua.edu.cn/simple然后单独装torch，这个不建议直接装在ultralytics依赖里让它自动拉，太大而且版本不一定带CUDA：
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu1212.2 没有GPU能跑吗
能跑，但别指望实时。YOLOv8n在CPU上跑一帧大概需要150~300毫秒，做视频分析可以，做实时监控就吃力了。如果你是做课设或者毕设，可以先用CPU把流程调通，最后换到实验室的GPU上跑正式效果。代码不需要大改，ultralytics会自动检测可用的设备。
注意：
torch.cuda.is_available()返回False不代表代码有问题，只是设备不对。很多人卡在这一步，以为装错了，其实是torch版本和CUDA版本不匹配。建议先跑一下python -c "import torch; print(torch.cuda.is_available())"，返回True再往下走。
3. 数据集构建：这是整个项目的地基
3.1 数据从哪来：自建还是用现成数据集
YOLO官方模型是在COCO数据集上训练的，COCO里确实有"bird"这个类别，但COCO的bird是天上飞的鸟，跟养殖场里密密麻麻的白羽鸡完全是两个概念。直接用yolov8n.pt的预训练权重检测鸡，效果只能说"偶尔能框出来"，漏检和误检都非常严重。
所以正规做法是：要么自己标注数据，要么找一个现成的家禽数据集来微调。网上确实有一些公开的鸡数据集，但质量参差不齐，标注框不贴边、类别混乱、场景单一的情况很常见。我的建议是：如果有条件，自建一部分数据再配合公开数据一起训，效果远比单一来源好。
3.2 标注实操：LabelImg的使用细节
标注工具我用的是LabelImg，虽然界面比较老，但胜在简单、直接生成YOLO格式的txt文件。安装是pip install labelimg，打开后先设置"PascalVOC"还是"YOLO"模式。这里有个巨大的坑：YOLO模式下生成的txt文件里，每个目标的格式是：
class_id center_x center_y width height注意这四五个数值全部是归一化的，也就是除以了图片的宽和高。很多人自己写代码读txt的时候忘了归一化这回事，直接把像素坐标当作归一化坐标用，结果训练出来检测框全偏到一边去。
标注的时候有个小技巧：不要贴着鸡的身体标框，稍微留一点边，大概1%~2%的余量。这样做的好处是，训练时Mosaic增强会把物体裁剪组合，如果标注框掐得太紧，增强后目标边缘信息损失会更明显。
3.3 数据划分
标注完之后，按7:2:1划分训练集、验证集、测试集。注意要按视频片段划分，不能随机打乱所有图片。理由很简单：视频相邻帧内容几乎一样，如果同一段视频的帧既出现在训练集又出现在验证集，那验证集就失去了意义，模型"见过"这些画面了。
我当时用的数据集规模供参考：视频抽帧8000张，剔除模糊和严重遮挡的废图后剩6200张，标注完成后训练集4400张、验证集1240张、测试集560张。这个规模训YOLOv8n够用了，训YOLOv8s也能凑合。
4. 训练过程：参数怎么调才有效
4.1 基础训练命令
数据准备好了，训练本身反而最简单。在ultralytics里，你需要准备一个data.yaml：
path: D:/chicken_dataset train: images/train val: images/valid nc: 1 names: ['chicken']然后一行命令开训：
yolo detect train data=chicken.yaml model=yolov8n.pt epochs=100 imgsz=640 batch=16 device=0这里有几个参数需要重点说：
imgsz：训练分辨率，我用的640。别为了追求性能把imgsz降到320，鸡是小目标，分辨率太低细节全没了。batch：如果显存不够，报"CUDA out of memory"，就往下调。8G显存跑YOLOv8s，batch=16会炸，老老实实改batch=8。epochs：100个epoch对自定义数据集来说是个保守但稳定的选择。我建议配合早停（patience=20）来用，模型收敛后自动停，省时间。
4.2 一个容易被忽略的参数：Mosaic增强
YOLOv8默认开启Mosaic增强，就是把4张图拼成一张喂进去。对大多数目标检测任务来说，这是个大杀器，模型泛化能力会提升不少。但在鸡这种目标密集且尺寸小的场景里，Mosaic会让目标变得更小，反而增加学习难度。
我的实测结论是：前30个epoch关闭Mosaic（mosaic=0.0），让模型先学会基本特征；30个epoch后开启Mosaic（mosaic=1.0），最后10个epoch再关闭。这样曲线走得又稳又好。你可以在训练参数里直接写mosaic=0.0，然后分阶段手动调整，或者用ultralytics里自带的schedule逻辑，都行。
4.3 训练过程中的观察指标
训练日志里有几个指标需要盯着看：
train/box_loss和train/cls_loss：持续下降就正常，震荡剧烈就要考虑学习率是不是太高，默认lr0=0.01通常没事。metrics/precision(B)：所有预测框中真正是鸡的比例。这个太高不一定是好事，可能说明模型很保守，只检置信度特别高的，漏检率高。metrics/recall(B)：所有真实的鸡被找回来的比例。这个太低就危险了，说明很多鸡压根没被框出来。metrics/mAP50(B)：这个是最直观的，mAP50超过0.9基本就能用了。
追求平衡，别追求单一指标。我见过有人把precision调到0.99，结果recall只有0.7，放在鸡舍里等于每3只鸡漏掉1只，这显然不合格。
提示：训练结束后会生成
best.pt和last.pt，推理一定要用best.pt。last.pt是最后一个epoch的权重，如果训练后期过拟合了，last.pt反而不如早停的best.pt。
5. 检测与跟踪落地：把"数鸡"这件事做扎实
5.1 单帧检测的推理代码
训练好模型后，最基础的推理代码非常简单：
from ultralytics import YOLO model = YOLO("runs/detect/train/weights/best.pt") results = model.predict("test.jpg", conf=0.35, iou=0.5) # results是一个列表，每张图一个元素 boxes = results[0].boxes for box in boxes: xyxy = box.xyxy[0].tolist() # 左上角右下角坐标 conf = box.conf[0].item() cls = int(box.cls[0].item()) print(xyxy, conf, cls)conf这个阈值值得细调。默认0.25，但在养殖场这种密集场景下，阈值设太低会出现大量误检框，设太高又漏检。我一般先跑一批测试图，画出来看效果，然后在0.3~0.5之间微调。密集场景我的常用值是0.35，加上NMS的iou=0.5，效果比较均衡。
5.2 跟踪接入：两种方式供选择
方式一：yaml配置方式（推荐）
ultralytics支持通过tracker参数指定配置文件：
from ultralytics import YOLO model = YOLO("best.pt") for frame in video_frames: results = model.track(frame, persist=True, conf=0.35, tracker="bytetrack.yaml") # results[0].boxes.id 就是每个框的跟踪ID这种方式最省事，bytetrack.yaml指定了跟踪器相关的参数，比如track_buffer和match_threshold。
方式二：自己拼装检测+跟踪
如果你对界面或者后处理的流程有更多定制需求，更推荐把检测结果拿出来自己喂给跟踪器：
from ultralytics import YOLO from collections import defaultdict track_history = defaultdict(list) def process_frame(frame): results = model.track(frame, persist=True, conf=0.35) if results[0].boxes is None or results[0].boxes.id is None: return frame, [] boxes = results[0].boxes.xyxy.cpu().numpy() track_ids = results[0].boxes.id.int().cpu().numpy() confs = results[0].boxes.conf.cpu().numpy() detections = [] for box, track_id, conf in zip(boxes, track_ids, confs): detections.append({ "id": track_id, "bbox": box, "conf": conf }) return frame, detections核心的persist=True不要漏掉，它告诉跟踪器保留上一帧的轨迹来匹配当前帧。如果漏了，每一帧都是重新开始，跟踪ID会反复横跳。
5.3 数据结构管理：内存不爆的诀窍
跟踪出来的数据，除了画框显示，往往还需要统计数量、画轨迹、甚至算密度。这里有个常见的坑：直接把所有帧的检测结果都存在列表里，跑个几分钟视频，内存就爆了。
我的做法是：只存一个固定长度的轨迹历史，比如每个track_id最多保留30帧的位置，用collections.deque(maxlen=30)，顺序弹出，内存占用恒定。
还可以在跟踪层做一次"区域过滤"。如果你只关心某个围栏里的鸡，可以在检测结果里加一道判断：
def in_region(bbox, region): cx = (bbox[0] + bbox[2]) / 2 cy = (bbox[1] + bbox[3]) / 2 # region是[x1, y1, x2, y2] return region[0] < cx < region[2] and region[1] < cy < region[3]中心点在区域内的才做跟踪和计数，这样既省算力，又避免边缘的无关目标干扰。
5.4 跨线计数：统计进出栏舍的数量
如果项目需求是"统计进出鸡舍的数量"，那需要在画面上画一条线，然后判断跟踪框中心是否跨线。逻辑比较朴素：记录每个track_id上一次的中心点坐标和当前的中心点坐标，如果从线的一侧到了另一侧，对应的计数器加一。
line_y = 400 # 横线在y=400的位置 crossed_ids = set() count_in = 0 count_out = 0 for track_id, cx, cy in current_positions: prev_y = track_last_y.get(track_id, None) if prev_y is not None: if prev_y < line_y and cy >= line_y: count_in += 1 crossed_ids.add(track_id) elif prev_y >= line_y and cy < line_y: count_out += 1 crossed_ids.add(track_id) track_last_y[track_id] = cy注意跨线只算一次，这里用set()记录已经结算过的ID，防止目标一直在线附近前后抖动导致重复计数。更严谨的做法是在跨线后延迟几帧再清除这个ID的跨线记录，否则同一只鸡跨进去又跨出来会被算成两次。
5.5 跟踪效果的调试技巧
- ID切换严重：把
match_threshold调低，比如从0.8降到0.6，让跟踪器更激进地匹配高置信度框。 - 跟踪框抖动：对框坐标做一次简单的平滑滤波，比如EMA（当前坐标乘以0.7加上一帧坐标乘以0.3），画面稳定性提升明显。
- 密集群体漏跟踪：在保证推理速度的前提下，把
conf从0.35降到0.25，让跟踪器能利用更多低置信度框做匹配。
6. UI界面设计与交互实现
6.1 界面选型：PySide6还是Gradio
这个项目标题里明确写了UI界面，就说明不是纯命令行环境。两条路线：
- PySide6/python桌面端：适合做实时监控、本地视频分析，交互强，部署有门槛但用户体验好。
- Gradio：适合做演示Demo，浏览器打开就能用，代码量极小，但没法做复杂的视频流实时交互，延迟高。
我强烈建议用PySide6。原因很简单：Gradio做出来的东西更像"给外行看的玩具"，而PySide6可以做出真正能在养殖场里跑的桌面软件，包括打开摄像头、选择视频文件、实时显示检测框、统计结果看板、参数调节面板，这些Gradio做起来都非常别扭。
6.2 界面布局设计
一个实用的界面布局一般是这样的：
- 左侧：视频显示区，占据主要面积，QLabel控件实时刷新画面。
- 右侧：控制区域，包括打开视频/摄像头按钮、暂停/继续按钮、置信度滑块、IOU滑块。
- 右侧下方：统计面板，显示当前画面中的鸡只数量、累计计数、每只鸡的跟踪ID列表。
- 顶部或底部：日志栏，显示检测和跟踪的耗时、当前模型路径。
界面代码本身不难，难的是怎么让视频流和UI不互相卡死。
6.3 线程设计：核心中的核心
之前提到主线程不能跑推理。我的做法是开一个QThread子线程专门做视频读取、检测、跟踪，然后把绘制好的帧通过Signal传回主线程的QLabel。
class DetectionThread(QThread): frame_ready = Signal(QImage) def __init__(self): super().__init__() self.model = YOLO("best.pt") self.is_running = True self.cap = None def run(self): while self.is_running: ret, frame = self.cap.read() if not ret: break results = self.model.track(frame, persist=True, conf=0.35) # 画出检测框和ID annotated_frame = results[0].plot() # 切换到RGB，转成QImage rgb_image = cv2.cvtColor(annotated_frame, cv2.COLOR_BGR2RGB) h, w, ch = rgb_image.shape bytes_per_line = ch * w qt_image = QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format.Format_RGB888) self.frame_ready.emit(qt_image.copy()) def stop(self): self.is_running = False self.wait()主线程这边，只需要连接信号槽：
self.detection_thread = DetectionThread() self.detection_thread.frame_ready.connect(self.update_frame) def update_frame(self, qt_image): self.video_label.setPixmap(QPixmap.fromImage(qt_image))这里有个很重要的细节：QImage创建时传的是rgb_image.data，而rgb_image是局部变量，出了作用域会被回收，所以emit之前必须调用.copy()，否则界面显示出来是花屏或者黑屏。
6.4 停止线程的坑：不要直接terminate
关闭窗口时，如果直接暴力关掉线程，可能出现"QThread: Destroyed while thread is still running"的崩溃。正确做法是先置is_running=False，然后调用wait()等待线程跑完当前循环。在closeEvent事件里做这个操作：
def closeEvent(self, event): self.detection_thread.stop() event.accept()stop()里已经带wait()了，主线程会等子线程安全退出再关窗口，这个习惯能帮你少掉一半莫名其妙的崩溃问题。
6.5 参数调节的实时生效
阈值滑块和检测框的实时联动，实现上不要走"滑一次重新初始化模型"的路子，那样太慢。正确做法是：用全局变量存当前的conf，每帧推理前从全局取值：
self.CONF_THRESHOLD = 0.35 def on_conf_changed(self, value): self.CONF_THRESHOLD = value / 100.0 # 在DetectionThread.run()里： results = self.model.track(frame, persist=True, conf=self.CONF_THRESHOLD)因为self对象是同一个线程的，读写这个数值没有竞争问题，不会崩。注意PySide6的滑块valueChanged信号发射频率很高，如果配置了100个刻度，每滑动1个刻度都会触发，但只要你的处理只是赋值一个浮点数，完全没压力。
7. 模型导出与推理加速
7.1 为什么导出ONNX
训练好的.pt权重在工程上并不好用，理由是依赖PyTorch环境，换台机器要重新搭环境，推理速度也不是最优。导出成ONNX格式后，可以脱离ultralytics环境跑推理，还能进一步转成TensorRT加速。
导出命令很简单：
yolo export model=best.pt format=onnx dynamic=False imgsz=640注意dynamic=False：ONNX默认会保留输入shape为动态，但动态shape在某些推理引擎（比如某些版本的onnxruntime）下性能会打折，而且跟踪任务里输入一般是固定640。固定shape在后续加速中更稳妥。
7.2 ONNX Runtime推理代码
导出来的ONNX，用onnxruntime跑：
import onnxruntime as ort import cv2 import numpy as np session = ort.InferenceSession("best.onnx", providers=["CUDAExecutionProvider", "CPUExecutionProvider"]) def infer(frame): img = cv2.resize(frame, (640, 640)) img = img[:, :, ::-1].transpose(2, 0, 1) # BGR转RGB，HWC转CHW img = np.ascontiguousarray(img, dtype=np.float32) img /= 255.0 # 归一化 # 加batch维度 input_tensor = img[None, ...] input_name = session.get_inputs()[0].name outputs = session.run(None, {input_name: input_tensor})[0] return outputs输出层的shape是[1, 84, 8400]，其中84=4个坐标+80个类别得分，因为导出的模型是COCO类别。如果你自定义了数据集的单类模型，应该是[1, 6, 8400]（4坐标+1类别+1置信度）。8400是三个尺度的预选框总数，这个值不用管，后处理时会做NMS过滤。
后处理NMS需要自己写，网上有很多现成的实现可以抄。但这里有个点：导出的ONNX不包含NMS，而model.predict()之所以能直接给你干净的框，是因为ultralytics内部帮你做了NMS。所以如果你不用ultralytics跑ONNX，就必须自己实现坐标解码+NMS这部分逻辑，难度不大但细节多。
7.3 TensorRT加速：实时项目的大招
如果是部署到有NVIDIA显卡的机器上，转成TensorRT带来的速度收益是实打实的。转换方法是用trtexec，或者用ultralytics直接导出engine：
yolo export model=best.pt format=engine device=0TensorRT会做层融合和精度校准（FP16），推理速度通常比onnxruntime快两倍以上。我实测下来，一张1080p的养殖场画面，TensorRT跑YOLOv8n能做到15毫秒左右一帧，加上跟踪和后处理不超过20毫秒，完全满足实时要求。
注意：TensorRT的engine和CUDA版本绑定，换机器后很可能加载失败，需要重新导出。这就是为什么导出ONNX更适合交付，而TensorRT更适合自用。
7.4 模型压缩：如果精度允许，试试v8n
YOLOv8有n、s、m、l、x五个尺寸，n是最轻的，模型参数量最小，推理最快。很多同学一上来就选YOLOv8m甚至YOLOv8x，觉得越大的模型精度越高，但忽略了"摄像头后的机器可能只是张老显卡"这个现实。
我做鸡检测项目时一开始用的是YOLOv8s，精度确实不错但帧率感人。后来测试YOLOv8n，在自建数据集上mAP50只掉了两个点左右，而帧率翻了一倍。如果你的场景是实时监控，建议先跑n版本，精度不够再走s，而不是一开始就上大模型。
8. 常见问题与排查技巧实录
8.1 检测效果差的排查顺序
很多人的第一反应是调阈值，其实不对。遇到检测效果差，我一般按这个顺序排查：
- 检查数据集质量：标注框是否贴边？有没有漏标目标？视频帧是否连续重复太多？这是最常见的原因。
- 检查训练设置：
imgsz是不是太小？batch是否过大导致没收敛？epochs是不是不够？ - 检查推理配置：
conf和iou是否合理？模型加载的是best.pt还是last.pt？ - 检查场景迁移：训练数据和测试数据的拍摄角度、光线、鸡的种类是否一致？如果训练集全是俯视视角，测试时换成平视视角，效果会急剧下降。
8.2 ID切换频繁怎么解决
这个问题在跟踪任务里几乎人人都会遇到。排查方向有这些：
- 检测质量是根本。跟踪的前提是检测稳定，如果同一只鸡在这一帧被框住、下一帧漏检、再下一帧又框住，跟踪器只能给新ID。所以先确认检测在连续帧上的稳定性，再谈跟踪。
track_buffer太短也容易造成ID切换。这个参数在bytetrack.yaml里，表示允许目标消失多少帧才删除轨迹。设成30，短时间遮挡后还能续上。- 卡尔曼滤波对运动模型有假设，鸡突然跳一下、扇翅膀，预测位置偏差大，匹配不上。这种情况下可以尝试降低
match_threshold，给匹配留一点容忍度。
8.3 界面卡顿或者黑屏
界面黑屏最常见的坑就是之前说的QImage内存被回收，解决办法就是.copy()。另一个常见问题是视频标签没有做缩放，大分辨率视频直接显示会非常卡。可以在update_frame里加上缩放，把QImage缩放到和QLabel大小一致后再设上去，能省一大笔绘制开销。
界面卡顿如果不是线程问题，那就是推理时间太长，显示帧率被拉得很低。这个时候优先考虑的是推理加速，而不是优化界面。
8.4 摄像头读取失败
摄像头打开失败常见有两个原因：一个是索引不对，笔记本多个摄像头的情况下cv2.VideoCapture(0)不一定是USB外接摄像头，可能要用1或者2；另一个是权限问题，有些系统下终端运行的Python没有摄像头访问权限，需要给终端授权。
USB摄像头长时间运行还有一个偶发问题：读取不到帧但程序不报错，一直循环read()返回False。建议做一个容错机制，连续30帧读取失败就自动切换回视频文件模式，或者弹出提示。
8.5 常见问题速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 检测框偏到图像边缘 | 标注txt没归一化 | 检查标注格式，除以图宽高 |
| 训练loss不降 | 学习率太高或数据太脏 | 调低lr0，清理错误标签 |
| 模型什么都检不出来 | 类别ID和names不匹配 | 检查data.yaml的nc和names |
| 推理速度慢 | 模型太大或没用GPU | 换YOLOv8n，开FP16推理 |
| 窗口无响应 | 主线程跑推理 | 改用QThread子线程 |
| 跟踪ID飘 | 检测不稳定 | 提高检测质量，调跟踪参数 |
| CPU飙升 | 视频分辨率太大 | 缩放输入帧，设置最大边 |
| 跨线重复计数 | ID在一条线附近反复横跳 | 加计数冷却，延迟清除crossed_ids记录 |
这些问题的共同根源，基本都是"某个环节的假设被打破"。YOLOv8本身是个成熟的工具，真正决定项目上限的其实是数据质量和工程细节。
9. 一点个人收尾
每次有人让我评价这类检测跟踪系统，我都是同一个说法：模型只是其中一半，另一半全在数据整理、参数工程和界面联调上。你把这个项目从"能跑demo"做到"能稳定数清楚鸡舍里的每一只鸡"，要经过的坑绝不是一个YOLOv8就能覆盖的。
根据我自己做类似项目的经验，有一个特别值得分享的小习惯：把所有视频测试素材和对应的标注结果固定下来，每隔一阵子就在同一份测试集上跑一次新的模型权重，对比mAP曲线。这样你能清楚地看到模型是越改越好还是越改越糟，而不是靠感觉判断。
如果你正卡在某个环节，建议按照文章的排查顺序从头捋一遍。大多数问题不是出在代码写错，而是出在数据处理或者线程模型选错了方向。希望这篇文章能帮你少走几条弯路。
