简介：本资源是一个基于YOLOv5目标检测与DeepSORT多目标跟踪的Web端部署实战项目，面向计算机视觉初学者与算法工程化实践者，解决目标检测模型落地为可交互Web服务的核心问题。压缩包共206个文件，包含56个Python源码（含模型训练、推理、Flask后端及前端交互逻辑）、21个YOLOv5相关配置yaml文件、96个编译后的pyc文件、3个MP4演示视频、3个JPG测试图像及Dockerfile、HTML页面等，整体约140.63MB，结构完整覆盖数据预处理、模型加载、跟踪逻辑封装与前后端联调全流程。已有168人学习下载，提供开箱即用的Flask部署方案、DeepSORT参数调优注释、YOLOv5与跟踪器协同集成要点，以及实际场景下的多目标ID持续性可视化示例，便于读者快速掌握从算法到服务的端到端工程实现路径。
1. 为什么用 YOLOv5 + DeepSORT + Flask 做实时多目标跟踪 Web 系统，反而比纯前端方案更稳、更准、更易调？
你有没有试过在浏览器里直接跑 YOLO 模型？TensorFlow.js 或 ONNX.js 虽然能加载权重，但一帧推理动辄 300–800ms（尤其在中低端 PC 或笔记本上），加上 JS 里做 Kalman 滤波和匈牙利匹配的开销，ID 切换频繁、轨迹抖动、漏检率飙升——这不是模型不行，是前端算力和调度机制天然不适合做「检测+跟踪」耦合任务。而本项目把 YOLOv5（轻量级 s/m 模型）和 DeepSORT（带外观特征提取的 ReID 模块）全放在后端 Python 进程里跑，只把原始视频流（或上传文件）送进来，后端完成推理→跟踪→轨迹聚合→JSON 结果返回，前端只负责渲染<canvas>和<video>标签，用requestAnimationFrame控制帧率，不碰模型、不碰矩阵运算。实测：RTX 3060 上单路 720p 视频可稳定 22–25 FPS；树莓派 5（4GB）部署yolov5s.pt+osnet_x0_25_msmt17.pt也能跑通 8–10 FPS，延迟 < 350ms。它不是“炫技型”Demo，而是面向安防巡检、仓储盘点、实验室行为分析等真实场景的最小可行闭环：模型可换、跟踪可调、接口可测、部署可缩容。适合已有 YOLO 训练经验、想快速把算法落地成 Web 工具的工程师，也适合需要交作业/参赛但不想被前端框架绑架的算法同学——Flask 不是最终生产框架，但它是最短路径验证「算法→服务→可视化」链路是否成立的那块试金石。
2. 从零构建 YOLOv5 + DeepSORT 后端服务：模型加载、推理流水线与跟踪状态管理
2.1 安装依赖与环境隔离：为什么不用 conda，而坚持 pip + requirements.txt？
YOLOv5 官方 repo（ultralytics/yolov5 v6.0–v7.0）对 PyTorch 版本敏感，DeepSORT 的torchreid子模块又要求torch>=1.9.0,<2.0.0，而 Flask 2.3+ 已弃用Werkzeug<2.3。若用 conda 创建环境，常因 channel 源混杂导致torch和torchvisionABI 不匹配（典型报错：undefined symbol: _ZNK3c104Type14is_subclass_ofERKS_）。我坚持用python -m venv yolov5-deepsort-env新建干净虚拟环境，再按顺序执行：
pip install --upgrade pip pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 --extra-index-url https://download.pytorch.org/whl/cu117 pip install -r requirements.txt其中requirements.txt内容严格锁定版本（关键项）：
Flask==2.2.5 numpy==1.23.5 opencv-python==4.8.1.78 pyyaml==6.0.1 requests==2.31.0 tqdm==4.66.1 ultralytics==8.0.194 # 注意：不是官方 yolov5，是 ultralytics 官方维护的统一接口（兼容 yolov5/v8/v10） torchreid==1.5.0 # DeepSORT 所需的 ReID backbone（osnet, resnet）提示：
ultralytics==8.0.194是当前（2024Q2）最稳定的版本，它把yolov5s.pt加载逻辑封装为YOLO('yolov5s.pt')，自动处理模型输入归一化、NMS 阈值、输出格式统一为Results对象，省去手动写torch.no_grad()和non_max_suppression的麻烦。别用git clone官方 yolov5 仓库——它的detect.py是脚本式设计，难以嵌入 Web 服务生命周期。
2.2 构建可复用的 Detector + Tracker 流水线：避免每次请求都 reload 模型
Web 服务最怕「每来一个 POST 请求就torch.load()一次模型」——yolov5s.pt（14MB）加载耗时 1.2–1.8s，osnet_x0_25_msmt17.pt（12MB）再加 0.9s，用户点一次「开始跟踪」要等 3 秒，体验崩坏。正确做法是：服务启动时一次性加载模型到内存，后续所有请求复用同一实例。
核心类YOLODeepSORTPipeline设计如下（tracker/pipeline.py）：
from ultralytics import YOLO from torchreid import models import torch import numpy as np class YOLODeepSORTPipeline: def __init__(self, det_model_path="yolov5s.pt", reid_model_path="osnet_x0_25_msmt17.pt"): # 1. 加载检测器（GPU 加速） self.detector = YOLO(det_model_path) self.detector.to('cuda' if torch.cuda.is_available() else 'cpu') # 2. 加载 ReID 模型（必须用 torchreid.models.build_model） self.reid_model = models.build_model( name='osnet_x0_25', num_classes=1000, loss='softmax', pretrained=False ) state_dict = torch.load(reid_model_path, map_location='cpu') self.reid_model.load_state_dict(state_dict) self.reid_model.to('cuda' if torch.cuda.is_available() else 'cpu') self.reid_model.eval() # 3. 初始化 DeepSORT 跟踪器（关键参数说明见 2.3 节） from tracker.deep_sort import DeepSort self.tracker = DeepSort( model_path=reid_model_path, max_dist=0.2, # 外观特征余弦距离阈值，>0.2 则认为非同一人 min_confidence=0.3, # YOLO 检测框置信度下限，低于此不送入跟踪器 nms_max_overlap=0.5, # 检测框 NMS IOU 阈值，抑制重叠框 max_iou_distance=0.7, # 匈牙利匹配时的 IOU 阈值（位置相似性） max_age=30, # ID 最长消失帧数（30 帧 ≈ 1 秒 @30FPS） n_init=3, # 新 ID 需连续 3 帧确认才激活 nn_budget=100 # 特征库最大缓存数，防内存爆炸 ) def process_frame(self, frame: np.ndarray) -> list: """ 输入：BGR 格式 OpenCV 图像（HWC） 输出：[{'track_id': int, 'bbox': [x1,y1,x2,y2], 'label': str, 'conf': float}, ...] """ # Step 1: YOLO 检测（自动归一化、NMS、返回 xyxy 格式） results = self.detector(frame, verbose=False) detections = [] for r in results: boxes = r.boxes.xyxy.cpu().numpy() # shape: (N, 4) confs = r.boxes.conf.cpu().numpy() # shape: (N,) classes = r.boxes.cls.cpu().numpy() # shape: (N,) for i in range(len(boxes)): if confs[i] >= self.tracker.min_confidence: x1, y1, x2, y2 = boxes[i] cls_id = int(classes[i]) label = self.detector.names[cls_id] # 如 'person', 'car' detections.append([x1, y1, x2, y2, confs[i], cls_id]) # Step 2: DeepSORT 跟踪（输入 detections，输出 tracked_objects） if len(detections) == 0: return [] # 转为 DeepSORT 所需格式：[x1,y1,x2,y2,conf,cls_id] detections = np.array(detections) tracks = self.tracker.update(detections, frame) # frame 用于 crop + 提取 ReID 特征 # Step 3: 格式化输出（适配前端 JSON 序列化） output = [] for track in tracks: bbox = track.to_tlbr() # [top, left, bottom, right] → 转为 [x1,y1,x2,y2] output.append({ "track_id": int(track.track_id), "bbox": [float(bbox[0]), float(bbox[1]), float(bbox[2]), float(bbox[3])], "label": self.detector.names[int(track.class_id)] if hasattr(track, 'class_id') else "unknown", "conf": float(track.conf) if hasattr(track, 'conf') else 1.0 }) return output这段代码的关键在于：
self.detector.to('cuda')和self.reid_model.to('cuda')必须显式指定设备，否则torchreid默认 CPU 推理，速度慢 5 倍；self.tracker.update(...)的第二个参数frame是必需的——DeepSORT 内部会根据bbox截取图像 patch，送入reid_model提取 512 维特征向量，没有原始 frame 就无法做外观匹配；track.to_tlbr()返回的是[top,left,bottom,right]（即y1,x1,y2,x2），需手动转为前端习惯的[x1,y1,x2,y2]，否则 canvas 绘制错位。
2.3 DeepSORT 的 4 个必调参数：为什么默认值在监控场景下必然翻车？
DeepSORT 不是开箱即用的黑盒。YOLOv5 检测框抖动、光照变化、遮挡频繁时，原版参数会让 ID 切换率高达 40%+。以下是我在 3 类典型场景（室内走廊、停车场出入口、实验室操作台）中反复验证的参数组合：
| 参数名 | 默认值 | 推荐值 | 作用说明 | 调参依据 |
|---|---|---|---|---|
max_dist | 0.2 | 0.18–0.22 | ReID 特征余弦距离阈值 | 0.18更严苛，减少跨 ID 匹配；0.22更宽松，适应光照突变。实测0.2在阴天走廊误匹配率 12%，调至0.19降至 4.3% |
max_iou_distance | 0.7 | 0.4–0.55 | 匈牙利匹配时 IOU 阈值 | 监控视频运动缓慢，0.7导致新旧 ID 过早合并。停车场车辆并行时，0.5可将 ID 切换率从 31% 降到 9% |
max_age | 30 | 20–25 | ID 最长消失帧数 | 30帧（1s）太长，遮挡后易错误复活旧 ID。实验室手部操作遮挡频繁，设22帧（≈0.73s）最佳 |
n_init | 3 | 2–3 | 新 ID 连续确认帧数 | 2加速 ID 创建，但增加误检风险；3更稳。建议固定3，靠min_confidence控制误检 |
血泪经验：不要迷信论文里的默认值。
max_iou_distance=0.7是针对 MOT16 数据集（高帧率、小目标、少遮挡）调优的，而你的监控视频往往是 25FPS、大目标、强遮挡——必须降档使用。我曾因没调max_iou_distance，导致同一辆车在路口转弯时被拆成 3 个 ID，客户当场质疑算法可靠性。
3. Flask Web 服务搭建：路由设计、视频流处理与前后端数据协议
3.1 单线程 vs 多线程：为什么 Flask 默认开发服务器不能跑实时视频？
Flask 自带的app.run()是单线程阻塞式服务器，同一时间只能处理一个请求。当你上传一个 60 秒 MP4 文件，后端要花 40 秒推理+跟踪，此时第二个用户刷新页面，请求会被挂起直到第一个完成——用户体验极差。必须启用多线程或异步模式。
正确启动方式（app.py）：
from flask import Flask, request, jsonify, render_template, Response from tracker.pipeline import YOLODeepSORTPipeline import threading import queue import time app = Flask(__name__) # 全局单例 pipeline（服务启动时加载） pipeline = YOLODeepSORTPipeline( det_model_path="weights/yolov5s.pt", reid_model_path="weights/osnet_x0_25_msmt17.pt" ) # 用线程安全队列暂存结果（避免全局变量竞争） result_queue = queue.Queue(maxsize=100) @app.route('/') def index(): return render_template('index.html') @app.route('/upload', methods=['POST']) def upload_video(): if 'video' not in request.files: return jsonify({"error": "No video file"}), 400 video_file = request.files['video'] if video_file.filename == '': return jsonify({"error": "Empty filename"}), 400 # 保存临时文件（生产环境应改用 Redis 或对象存储） temp_path = f"temp/{int(time.time())}_{video_file.filename}" video_file.save(temp_path) # 启动后台线程处理（非阻塞） def process_and_enqueue(): cap = cv2.VideoCapture(temp_path) frame_count = 0 while cap.isOpened(): ret, frame = cap.read() if not ret: break # 每 2 帧处理一次（降负载，保实时性） if frame_count % 2 == 0: try: results = pipeline.process_frame(frame) result_queue.put({ "frame_id": frame_count, "tracks": results, "timestamp": time.time() }) except Exception as e: print(f"Frame {frame_count} error: {e}") frame_count += 1 cap.release() # 标记结束 result_queue.put({"end": True}) threading.Thread(target=process_and_enqueue, daemon=True).start() return jsonify({"status": "processing", "video_id": temp_path.split('/')[-1]}) @app.route('/stream') def stream(): def generate(): while True: try: # 非阻塞获取，超时 1s 防卡死 item = result_queue.get(timeout=1.0) if "end" in item: yield f"data: {json.dumps({'end': True})}\n\n" break yield f"data: {json.dumps(item)}\n\n" result_queue.task_done() except queue.Empty: yield f"data: {json.dumps({'ping': time.time()})}\n\n" return Response(generate(), mimetype='text/event-stream')关键点解析：
threading.Thread(target=..., daemon=True)：后台线程，主进程退出时自动销毁，避免僵尸进程；result_queue作为线程间通信桥梁，容量限制maxsize=100防内存溢出；/stream路由采用SSE（Server-Sent Events）协议，而非 WebSocket——SSE 更轻量、兼容性更好（IE11+ 支持），且天然支持文本流，适合推送 JSON 轨迹数据；frame_count % 2 == 0是主动降帧策略：YOLOv5s 在 1080p 下单帧推理约 45ms，25FPS 视频若全帧处理需 1125ms/s，超 GPU 负载；跳帧后实际处理 12.5FPS，延迟可控且 ID 连续性无损。
3.2 前端 Canvas 渲染：如何用 requestAnimationFrame 同步后端 SSE 流？
前端index.html中，核心渲染逻辑如下（static/js/app.js）：
let canvas, ctx, video; let currentFrameId = -1; let tracksCache = {}; // {frame_id: [...tracks]} function initCanvas() { canvas = document.getElementById('detectionCanvas'); ctx = canvas.getContext('2d'); video = document.getElementById('videoInput'); // 动态设置 canvas 尺寸匹配视频 video.addEventListener('loadedmetadata', () => { canvas.width = video.videoWidth; canvas.height = video.videoHeight; }); } async function startStreaming() { const eventSource = new EventSource('/stream'); eventSource.onmessage = (event) => { const data = JSON.parse(event.data); if (data.end) { console.log('Tracking finished'); eventSource.close(); return; } if (data.frame_id !== undefined) { tracksCache[data.frame_id] = data.tracks; // 触发下一帧渲染（requestAnimationFrame 保证 60FPS 渲染节律） if (currentFrameId < data.frame_id) { currentFrameId = data.frame_id; renderFrame(); } } }; eventSource.onerror = (err) => { console.error('SSE error:', err); }; } function renderFrame() { if (!video.paused && video.readyState === video.HAVE_ENOUGH_DATA) { // 清空画布 ctx.clearRect(0, 0, canvas.width, canvas.height); // 绘制视频帧（注意：drawImage 会拉伸，需保持宽高比） ctx.drawImage(video, 0, 0, canvas.width, canvas.height); // 绘制轨迹框（仅渲染当前帧 tracks） const tracks = tracksCache[currentFrameId] || []; tracks.forEach(track => { const [x1, y1, x2, y2] = track.bbox; ctx.strokeStyle = `hsl(${track.track_id * 43 % 360}, 100%, 50%)`; // 彩虹色 ID ctx.lineWidth = 2; ctx.strokeRect(x1, y1, x2 - x1, y2 - y1); // 绘制 ID 标签 ctx.fillStyle = 'white'; ctx.font = '14px sans-serif'; ctx.fillText(`ID:${track.track_id} ${track.label}`, x1 + 5, y1 - 10); }); } requestAnimationFrame(renderFrame); // 持续循环 } // 页面加载完成后初始化 document.addEventListener('DOMContentLoaded', () => { initCanvas(); startStreaming(); });玄学细节：
ctx.drawImage(video, 0, 0, canvas.width, canvas.height)会强制拉伸视频填充 canvas，但 YOLO 输出的bbox坐标是基于原始分辨率的。解决方案是：让 canvas 尺寸始终等于 video 的videoWidth/videoHeight（通过loadedmetadata事件监听），这样坐标无需缩放，直接绘制即可。若强行用 CSS 缩放<video>标签，bbox必须按比例换算，极易出错。
4. Docker 部署实战：Dockerfile 编写、GPU 支持与体积优化
4.1 最小可行 Dockerfile：为什么 base 镜像选nvidia/cuda:11.7.1-devel-ubuntu20.04？
很多教程用python:3.9-slim，但slim镜像不含nvidia-smi、libcuda.so等 GPU 运行时库，即使安装nvidia-container-toolkit也无法调用 GPU。必须用 NVIDIA 官方 CUDA base 镜像：
# 使用 NVIDIA 官方 CUDA 开发镜像（预装 cudnn、cuda-toolkit） FROM nvidia/cuda:11.7.1-devel-ubuntu20.04 # 设置环境 ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone ENV DEBIAN_FRONTEND=noninteractive # 安装系统依赖（OpenCV 需要） RUN apt-get update && apt-get install -y \ libglib2.0-0 \ libsm6 \ libxext6 \ libxrender-dev \ libglib2.0-dev \ && rm -rf /var/lib/apt/lists/* # 创建工作目录 WORKDIR /app COPY requirements.txt . # 分层安装：先装 torch（耗时最长），再装其他 RUN pip install --no-cache-dir torch==1.13.1+cu117 torchvision==0.14.1+cu117 --extra-index-url https://download.pytorch.org/whl/cu117 RUN pip install --no-cache-dir -r requirements.txt # 复制代码 COPY . . # 暴露端口 EXPOSE 5000 # 启动命令（--host=0.0.0.0 绑定所有网卡，--port=5000 指定端口） CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "2", "--threads", "4", "--timeout", "120", "app:app"]关键点说明：
nvidia/cuda:11.7.1-devel-ubuntu20.04是 PyTorch 1.13.1 的官方推荐 base，ABI 兼容性最好；gunicorn替代flask run：支持多 worker（--workers 2）、多线程（--threads 4），吞吐量提升 3 倍以上；--timeout 120防止大视频处理超时被 kill；libsm6、libxext6是 OpenCV GUI 模块依赖，缺失会导致cv2.VideoCapture初始化失败（报错libSM.so.6: cannot open shared object file）。
4.2 GPU 容器运行命令：nvidia-docker 与 docker run 的区别在哪？
docker run默认无法访问 GPU，必须显式添加--gpus all参数：
# 构建镜像 docker build -t yolov5-deepsort-web . # 运行容器（关键：--gpus all + --shm-size=2g） docker run -d \ --gpus all \ --shm-size=2g \ -p 5000:5000 \ -v $(pwd)/weights:/app/weights \ -v $(pwd)/temp:/app/temp \ --name yolov5-web \ yolov5-deepsort-web--gpus all：挂载所有 GPU 设备（/dev/nvidia0,/dev/nvidiactl等）；--shm-size=2g：必须设置！YOLO 推理时 OpenCV 的cv2.dnn模块使用共享内存加速，默认64MB不够，会导致cv2.VideoCapture读帧卡死或报Failed to allocate memory；-v $(pwd)/weights:/app/weights：将本地weights/目录挂载进容器，避免重新打包镜像。
避坑：不要用
nvidia-docker命令（已废弃），docker run --gpus是 Docker 19.03+ 的标准语法。若报错docker: Error response from daemon: could not select device driver "nvidia", 请检查nvidia-container-toolkit是否安装并配置/etc/docker/daemon.json。
5. 避坑指南：YOLOv5 + DeepSORT + Flask 部署的 5 个高频翻车点
5.1 现象：Flask 启动后报错ImportError: libcudnn.so.8: cannot open shared object file
原因：CUDA base 镜像中libcudnn.so.8路径未加入LD_LIBRARY_PATH，或 PyTorch 安装的 cudnn 版本与镜像不匹配。
解决：在 Dockerfile 中显式导出路径，并验证 cudnn 版本：
# 在 RUN pip install ... 后添加 RUN echo '/usr/lib/x86_64-linux-gnu' >> /etc/ld.so.conf.d/cuda.conf && ldconfig RUN python -c "import torch; print(torch.backends.cudnn.version())" # 应输出 8.5.05.2 现象：前端 canvas 显示黑屏，但控制台无报错
原因：<video>标签未设置autoplay和muted，现代浏览器禁止自动播放有声音的视频。
解决：HTML 中<video>标签必须加autoplay muted loop：
<video id="videoInput" autoplay muted loop style="display:none;"></video>同时 JS 中用video.src = URL.createObjectURL(file)加载文件后，需手动调用video.play()。
5.3 现象：DeepSORT 跟踪 ID 频繁闪烁（同一目标 ID 在 1/2/3 间跳变）
原因：max_iou_distance过高（如 0.7）+max_dist过低（如 0.15），导致匈牙利匹配优先选 IOU 高但外观差异大的框，ReID 特征被忽略。
解决：按 2.3 节表格，将max_iou_distance降至 0.45–0.5，max_dist设为 0.2，二者权重均衡。
5.4 现象：上传 MP4 后/stream返回 404，或 SSE 连接立即关闭
原因：Flask 路由/stream未正确返回Response对象，或generate()函数未yield字符串（如忘了\n\n）。
解决：严格按 3.1 节代码，确保yield f"data: ...\n\n"，且mimetype='text/event-stream'；检查app.py是否from flask import Response。
5.5 现象：Docker 容器内cv2.VideoCapture无法打开本地 MP4 文件，报Unable to load from file
原因：OpenCV 缺少 FFmpeg 后端支持，Ubuntu base 镜像默认不装ffmpeg。
解决：在 Dockerfile 中apt-get install补充：
RUN apt-get install -y ffmpeg libavcodec-dev libavformat-dev libswscale-dev libv4l-dev && rm -rf /var/lib/apt/lists/*并验证cv2.getBuildInformation()中FFMPEG: YES。
6. 进阶技巧：如何用 Redis 缓存轨迹、支持多路并发与前端性能压测
6.1 用 Redis 替代内存队列：解决高并发下的 result_queue 溢出问题
当 10 个用户同时上传视频，queue.Queue容量maxsize=100会迅速填满，新结果被丢弃。改用 Redis List 作为消息队列，天然支持多消费者、持久化、长度限制：
import redis r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True) @app.route('/upload', methods=['POST']) def upload_video(): # ... 保存文件逻辑 ... # 生成唯一 job_id job_id = f"job_{int(time.time())}_{uuid.uuid4().hex[:6]}" # 将 job_id 推入 Redis 队列 r.lpush('tracking_jobs', job_id) r.hset(f"job:{job_id}", mapping={ "status": "queued", "video_path": temp_path, "created_at": time.time() }) # 启动 Celery 任务（或独立进程）处理 job_id # 此处省略 Celery 配置，可用 subprocess.Popen 调用独立脚本 subprocess.Popen(["python", "worker.py", job_id]) return jsonify({"job_id": job_id}) @app.route('/result/<job_id>') def get_result(job_id): # 从 Redis 获取该 job 的最新轨迹（每秒轮询） tracks = r.lrange(f"job:{job_id}:tracks", 0, -1) return jsonify({"tracks": [json.loads(t) for t in tracks]})好处：Redis List 支持
LLEN查长度、LTRIM限长、BLPOP阻塞读，比 Pythonqueue更健壮；且可轻松扩展为多 worker 消费，支撑百路并发。
6.2 前端性能压测：用 Chrome DevTools 模拟 3G 网络与低端设备
真实用户可能用 4G 网络看 1080p 视频，前端渲染压力巨大。在 Chrome DevTools → Network → Throttling 中选择Fast 3G，再开启 Rendering → FPS Meter，观察：
- 若 FPS < 30，说明
requestAnimationFrame渲染跟不上，需降低canvas分辨率（如canvas.width = video.videoWidth * 0.5）； - 若内存占用持续上升（Memory tab），说明
tracksCache未清理旧帧，需加定时清理：
// 每 5 秒清理超过 100 帧的缓存 setInterval(() => { const keys = Object.keys(tracksCache); if (keys.length > 100) { const oldest = Math.min(...keys.map(Number)); delete tracksCache[oldest]; } }, 5000);6.3 模型热切换：不重启服务更换 YOLO 权重文件
生产环境常需 A/B 测试不同模型（如yolov5s.ptvsyolov5m.pt）。修改pipeline.py，支持运行时 reload：
class YOLODeepSORTPipeline: def __init__(self, ...): # ... 初始化代码 ... self._det_model_path = det_model_path # 缓存路径 def reload_detector(self, new_path: str): """热加载新检测模型""" self.detector = YOLO(new_path) self.detector.to(self.device) self._det_model_path = new_path print(f"Detector reloaded from {new_path}") @property def device(self): return next(self.detector.model.parameters()).device然后新增 Flask 路由：
@app.route('/reload-detector', methods=['POST']) def reload_detector(): data = request.get_json() new_path = data.get('path') if not new_path or not os.path.exists(new_path): return jsonify({"error": "Invalid path"}), 400 pipeline.reload_detector(new_path) return jsonify({"status": "success", "new_model": new_path})我的习惯：上线前必做三件事——用
cv2.VideoCapture本地跑通单帧推理；用curl -X POST测试/upload接口返回；用 Chrome Network Tab 看/stream是否持续收到data:块。这三步过了，90% 的部署问题已排除。剩下 10% 是客户现场的网络波动和摄像头型号兼容性，那得靠日志和cv2.CAP_PROP_FOURCC调试。希望帮到你。
本文还有配套的精品资源，点击获取
