最新YOLO+Flask+SocketIO实现疲劳驾驶实时检测平台

做驾驶疲劳检测这个方向，有个现实问题一直没被解决：市面上的方案要么贵，要么是个黑盒，要么部署起来能把人绕晕。我自己折腾过几套检测流程，最后稳定跑下来的这套，就是标题里写的组合——最新YOLO负责视觉识别，Flask+SocketIO负责把能力变成实时可交互的Web页面，前端用HTML/CSS/JS做展示和控制。整套平台的完整名字就叫：最新YOLO实现的疲劳驾驶实时检测平台（Flask+SocketIO+HTML/CSS/JS）。

它解决的问题不复杂：摄像头里识别驾驶员的面部状态，判断眼睛是否闭合、嘴巴是否张大（打哈欠）、有没有频繁点头，在一段时间内连续出现这些行为就判定为疲劳，并在浏览器端立刻弹出告警。整套平台不依赖重型客户端，打开一个网页就能用，局域网内谁都能访问，适合放在模拟驾驶舱、教学实验、智能座舱demo这些场景里。

适合谁来参考？如果你刚接触实时视频处理，想快速上手一套前后端联通的检测系统；或者你在做智能座舱方向的演示项目；又或者你只是好奇WebSocket前后端怎么配合模型推理，这套思路都可以直接套。下面我就把整套设计和踩过的坑拆开讲清楚。

1. 项目整体设计与思路拆解

1.1 一个实时检测系统要拆成哪几层

很多人上手这类项目，第一反应是"先找个YOLO模型，把视频丢进去，检测完显示结果"。但真正写起来会发现，实时检测比离线推理麻烦得多。摄像头帧要以每秒几十张的速度进来，模型推理要占用时间，结果要回传给前端，前端还要按帧更新画面，任何一个环节卡住，整个平台就变成幻灯片。

所以我在设计时把系统拆成四个独立层次：视频采集层、模型推理层、后端服务层、前端展示层。你可以想象成一条流水线：采集层负责"原料"（视频帧）按稳定节奏送入，推理层是"质检工"（YOLO检测+关键点计算），后端服务层是"调度中心"（Flask+SocketIO接收、处理、广播结果），前端展示层是"看板"（HTML/CSS/JS渲染状态和告警）。每一层只做自己的事，层与层之间通过约定好的数据格式通信，这样后面替换任何一层（比如换模型、换前端框架）都不会牵一发动全身。

这里有个关键选择：视频帧到底走什么链路？我采用的是"浏览器采集、SocketIO上传、后端推理、结果广播回前端"的方式。也就是说摄像头画面先通过浏览器的getUserMedia拿到，原视频流直接显示在本地页面上（这个延迟最低），同时把每一帧压缩成JPEG再用SocketIO发到后端。后端完成YOLO推理和疲劳判定后，把结果推给前端，前端根据结果在本地画面上叠加检测框和状态信息。这么做的原因是部署最省事——后端完全不碰摄像头设备，逻辑简单，一台服务器可以对接多路浏览器客户端。

1.2 为什么选Flask+SocketIO而不是Django轮询

先说一个常识：实时检测平台里，"实时"两个字是核心需求。传统HTTP请求是无法保持长连接的，前端每隔几百毫秒就请求一次后端接口，叫"轮询"。轮询的毛病很明显——大部分请求是空转的，后端没有结果也得回一趟空数据，带宽浪费很严重，而且轮询频率一提高，并发一上来，后端服务很容易被打满。

SocketIO的核心是WebSocket，它是全双工的长连接，建立一次连接后，后端可以主动把数据推给前端，不需要前端反复来问。拿生活中的例子类比：HTTP轮询就像每隔一分钟就去冰箱看一眼牛奶有没有喝完，而WebSocket相当于冰箱主动发消息告诉你"牛奶快没了"。对于疲劳检测这种需要秒级甚至毫秒级告警的场景，推送能力是必须的。

选Flask而不是Django，是因为Flask足够轻量，这个项目核心是"实时通信+模型推理"，不需要Django自带的ORM、Admin后台、表单系统这些重量级模块。Flask+SoketIO（注意是python-socketio库）组合，代码量少，境界清晰，适合快速落地。而且SocketIO带自动重连、事件命名空间、房间管理等功能，后面如果要做"多路摄像头同时检测"，直接按通道绑定房间就行，不用自己再造轮子。

1.3 为什么选YOLO而不是传统图像处理方案

传统做疲劳检测，常见的是用Haar级联或HOG+SVM把人脸框出来，再用ASM或者光流法定位眼睛和嘴巴。这套方案在光线稳定的室内还行，但一旦遇到大光比（逆光、夜间车灯照射）、驾驶员戴墨镜、侧脸角度大、画面抖动等情况，召回率会掉得非常厉害。传统特征工程受限于人工设计的特征表达能力，很难覆盖真实驾驶舱的复杂环境。

YOLO是端到端的目标检测网络，直接把"图像像素"映射为"目标类别+位置框"，在复杂背景下的鲁棒性明显更好。而且"最新YOLO"这里有个实操层面的优势：模型迭代快，官方仓库提供了足够多的预训练权重和部署导出工具，我们不需要从零训练。对于疲劳检测这个任务，YOLO的定位不是直接输出"疲劳/不疲劳"，而是先完成两个基础任务——检测驾驶员人脸区域、定位面部关键点，然后再用工程指标去判定疲劳状态。这样模型是通用的，疲劳判定逻辑是独立的，换场景只需要重新标定指标阈值，不用重新训模型。

考虑到实时性，模型参数不能选太大。我在这个项目里用的是轻量化版本（nano级），同时开启了推理时的固定分辨率（如640x640）和半精度推理。如果你是NVIDIA显卡环境，还可以导出TensorRT引擎进一步提速；如果是CPU环境，建议导出ONNX后用OpenVINO推理，速度能翻好几倍。

2. 疲劳检测模型选型与关键参数

2.1 YOLO版本与预训练权重怎么挑

虽然标题叫"最新YOLO"，但我不建议盲目追版本号。我实际用的是当前比较稳定的YOLOv8系列，如果你拿到的是更新的版本，API和训练导出流程基本能无缝迁移，甚至更简便。这个项目的核心是"用YOLO做人脸框+关键点检测"，所以版本之间的差别主要体现在速度和精度上，架构迁移成本很低。

选预训练权重是个容易犯错的点。很多人直接下载官方COCO权重就拿来跑，COCO权重里有person类别，能勉强框出人脸，但框不准，小脸、侧脸经常漏检，更没有关键点输出。正确做法是选人脸检测专用权重，或者用大型人脸数据集（WIDER FACE等）重新训练人脸检测分支。如果你不想自己训练，网上有不少成熟的YOLO人脸检测权重，下载后放进权重目录就能用。这里的关键是：先验证"人脸框检测+关键点检测"两个基本任务的可视化效果，再去做疲劳逻辑，否则后面一切指标都是空中楼阁。

我用的是这么一套组合：YOLO人脸检测模型负责输出人脸四角坐标和置信度，然后裁剪人脸区域，再交给一个轻量级人脸关键点模型（输出眼睛、眉毛、鼻子、嘴巴等关键点）。如果环境能跑更大的模型，也可以换成同时输出人脸框和关键点的统一模型，但那样调试时模型内部耦合度高，一旦关键点飞点，你很难判断是人脸检测的问题还是关键点头的问题。

2.2 人脸关键点检测的两种路线对比

路线一是用带关键点输出的YOLO变体，通过修改检测头，直接回归每个人脸的N个关键点。路线二是"检测+裁剪+轻量关键点模型"的两段式方案，YOLO只负责框出人脸区域，裁剪后交给另一个模型（比如基于热力图回归的轻量模型）提取关键点坐标。

我推荐路线二，原因很实际：第一，两个模型可以分别调优。人脸检测置信度低了，就调YOLO的conf阈值；关键点抖动厉害，就在关键点模型内部做平滑，互不干扰。第二，可替换性好。后面如果发现某个人脸关键点模型在戴眼镜场景下表现差，直接换一个关键点模型，不需要动YOLO。第三，训练数据好组织。人脸检测数据集和关键点数据集是分开的，这在准备数据阶段能省大量时间。缺点也明显：多了一次裁剪和一次推理，延迟会增加几毫秒到十几毫秒，但实测下来在10FPS处理节奏下完全能接受。

关键点数量方面，常规模型有5点、68点、104点等方案。做疲劳检测其实用不了那么多点。眼睛闭合判断只需要每只眼的6个关键点（上下眼睑各2个、左右眼角各1个），嘴巴开合判断只需要嘴部周围4个或6个点。如果关键点模型给的是68点，我们取眼睛和嘴巴区域对应的索引即可；如果只有5点（左右眼中心、鼻子、左右嘴角），那只能做简单状态估计，精度不够做疲劳检测，建议至少要有34点以上的模型。

2.3 疲劳判定指标与阈值设计

这是整个平台的核心，我把公式和阈值都写清楚。判定疲劳不是"某一帧闭眼了就报警"，那会疯狂误报。工程上要用时间段内的统计指标，常见的有三个：

第一个是眼睛纵横比EAR（Eye Aspect Ratio）。眼睛关键点确定后，取左眼和右眼各自关键点，EAR公式为：EAR = (||p2 - p6|| + ||p3 - p5||) / (2 * ||p1 - p4||)，即眼睛上下眼睑的垂直距离之和除以水平眼裂宽度的两倍。人正常睁眼时EAR大约在0.25到0.35之间，闭眼时会掉到0.1以下。这个数值和个体的眼睛大小有关，所以不许直接拿别人项目的0.2来用，第一次运行前要把现场人员的正常睁眼EAR统计出来，取一个比正常值低30%左右的数做阈值。

第二个是嘴巴纵横比MAR（Mouth Aspect Ratio），用于判断打哈欠。嘴部关键点取上下嘴唇两对点和左右嘴角点，MAR = (||p1 - p5|| + ||p2 - p4||) / (2 * ||p3 - p6||)。正常说话时MAR小幅度波动，打哈欠时嘴部垂直距离明显增大，MAR会超过日常说话时的峰值。判断哈欠同样不能只看一帧，要连续超过一定帧数或者持续一定时间才算一次哈欠。

第三个是点头频次。通过头部姿态估计（通常由关键点计算pitch角）检测低头动作，在一段时间内低头次数过多视为疲劳。这个指标不是必须的，但加上以后能明显降低漏报，因为有些疲劳的人是靠点头而不是打哈欠表现。

更核心的统计指标是PERCLOS，即单位时间内眼睛闭合帧数占总帧数的比例。计算方式是：取一个滑动窗口（比如30秒），统计EAR低于闭眼阈值的帧数除以窗口内总帧数，当PERCLOS超过一定比例就判定疲劳。疲劳研究文献中常用0.4作为重度疲劳阈值，但在实际工程里，我习惯把告警分成两级：PERCLOS超过0.2提示"轻度疲劳"，超过0.4触发"疲劳告警"。因为真实场景光线、脸型差异大，宁可给现场留出校准空间，也不要在第一版就卡死在一个数值上。

下面给一个EAR计算的实际示例：假设某只眼的关键点坐标分别为p1(10,10)、p2(11,13)、p3(15,14)、p4(20,16)、p5(22,11)、p6(16,9)，计算得到上睑两点距离为|p2-p6|约等于5.4，下睑两点距离为|p3-p5|约等于7.3，水平距离|p1-p4|为15。EAR = (5.4 + 7.3) / (2 * 15) = 0.423，这是睁眼状态。如果是闭眼，上下睑距离会显著压缩，EAR掉到0.1左右。

补充一个代码推算细节：实际项目里关键点坐标是浮点数，距离计算应该用欧氏距离，而不是简单的像素差绝对值。还有，眼睛小的人EAR天生偏低，所以系统里最好加一个"个体校准"流程，开始时让驾驶员睁眼和闭眼各几秒，自动记录专属阈值，这一招能解决大部分误报问题。

3. 后端服务搭建与实时通信

3.1 Flask应用结构与SocketIO初始化

后端结构我建议保持轻量，不要一上来就分一堆包，代码量不达规模时反而累赘。我在项目里的目录大致如下：

text复制app.py                 // Flask入口 + SocketIO初始化 + 路由
camera_stream.py       // 前端帧接收与预处理逻辑
yolo_detector.py       // YOLO模型加载、推理、关键点提取
fatigue_evaluator.py   // EAR/MAR/PERCLOS计算与状态机
config.py              // 阈值、路径、模型参数配置
templates/             // 前端HTML模板
static/                // 前端CSS/JS文件

Flask和SocketIO的初始化代码很简单，但有几个坑要提前避开。第一个坑是模型加载位置，千万别在请求函数里加载模型，那会让第一个请求卡几秒甚至几十秒，还可能在并发时重复加载把内存吃爆。正确做法是在模块加载时初始化一次全局模型对象，后面所有请求都复用同一个模型实例。第二个坑是跨域限制，浏览器里WebSocket请求会有CORS校验，如果不带cors_allowed_origins参数，浏览器会直接拦截，所以初始化时显式设置允许来源。第三个坑是当使用多线程处理时，Flask开发服务器默认线程模式与SocketIO的并发模型可能冲突，后面会在部署篇专门说。

初始化代码示例：

python复制from flask import Flask, render_template
from flask_socketio import SocketIO

app = Flask(__name__)
app.config["SECRET_KEY"] = "fatigue-detection-secret"
socketio = SocketIO(app, cors_allowed_origins="*")

# 全局唯一的检测器实例，服务启动时加载
detector = FatigueDetector(config_path="config.yaml")

@app.route("/")
def index():
    return render_template("index.html")

if __name__ == "__main__":
    # 注意不用 app.run，而是 socketio.run
    socketio.run(app, host="0.0.0.0", port=5000, debug=True)

这里有一个很容易被忽略的点：socketio.run不等于app.run，它内部会启动支持WebSocket的服务器。如果项目跑在开发调试阶段，这个写法够用；但生产环境建议换成gunicorn等服务器配合eventlet/gevent worker，这个在后面的部署排查部分展开。

3.2 视频帧上传与推理主流程

前端采集到一帧后，通过canvas.toDataURL("image/jpeg", 0.7)把图像压缩成JPEG的base64字符串，然后通过SocketIO发送到后端。这里也有一个权衡：base64会让数据体积膨胀约33%，不太适合公网超低带宽环境，但在局域网演示场景下完全没问题。如果你追求极致带宽，可以改用二进制buffer直接发送，但处理起来会稍微麻烦一点，还要自己处理分包与重组。

后端在video_frame事件里接收帧数据，核心处理流程依次是：base64解码、图像解码、缩小分辨率、送入YOLO检测人脸、裁剪人脸送入关键点模型、计算EAR/MAR/PERCLOS指标、更新疲劳状态机、把结果广播回前端。我在处理时做了跳帧优化，不需要每帧都推理，通常4帧里只推理1帧，其余帧直接用上一次的检测结果，前端画面却依然是流畅的，这个优化能省掉一大半推理负载。

后端关键代码示例：

python复制import base64
import cv2
import numpy as np
from flask_socketio import emit

@socketio.on("video_frame")
def handle_video_frame(data):
    # data结构：{"frame": base64字符串, "client_id": "xxx"}
    frame_b64 = data.get("frame")
    if not frame_b64:
        return

    img_bytes = base64.b64decode(frame_b64.split(",")[-1])
    img_arr = np.frombuffer(img_bytes, dtype=np.uint8)
    frame = cv2.imdecode(img_arr, cv2.IMREAD_COLOR)
    # 缩放推理分辨率，控制耗时
    frame = cv2.resize(frame, (0, 0), fx=0.75, fy=0.75)

    # 执行人脸框+关键点+疲劳指标计算
    result = detector.process_frame(frame)

    # 把结果推送到该客户端对应的房间
    result["client_id"] = data.get("client_id")
    room = f"driver_{data.get('client_id')}"
    emit("detection_result", result, room=room)

这里需要特别注意的是emit的room参数，它决定结果推给谁。如果有多路摄像头同时接入，每路摄像头用不同的client_id绑定到不同房间，后端处理好每个房间的独立状态机，互不串数据。一个常见的错误是所有人都往默认房间发，结果A房间的告警推到了B房间的前端页面，这个问题在项目一开始就要通过房间机制规避。

还有一点，前端发送帧的频率不建议无限提高。我用10FPS的发送频率，也就是每100毫秒一帧，这已经能满足疲劳判定需求。因为PERCLOS统计本质上是时间占比，10FPS在30秒窗口能采集300帧，统计学上足够稳定。

3.3 推理线程与事件广播设计

Flask开发模式下，SocketIO是事件驱动模型，同一时刻可能有多个客户端发来帧。如果在每个事件里都同步执行模型推理，推理耗时会造成事件队列堵塞——一个慢帧卡住，后面所有帧都跟着排队。实测下YOLO轻量模型单帧推理大约15到30毫秒，情况还好，但如果模型稍大或者并发客户端一多，就必须把推理放到后台线程。

我在项目中采用的做法是：SocketIO事件处理器只负责接收帧数据、放入队列，后台单独起一个消费者线程持续从队列取帧、推理、发结果。这样的好处是前端上传帧不会阻塞，推理慢的时候队列可以积压几帧，不至于让事件循环停摆。队列用Python的queue.Queue即可，容量控制在一两百帧，超出就丢弃旧帧，保证系统始终处理最新状态而不是积压老帧。

事件广播设计上，需要区分两类事件：detection_result按房间定向发送，给特定客户端更新画面和状态；alert_event是系统级告警，可以广播到所有管理端页面，便于监控人员看到所有车辆的告警情况。我实际项目中前端管理端页面会在告警时弹窗+播放声音，这个完全靠SocketIO的推送能力实现。

4. 前端可视化与管理面板

4.1 页面布局与实时视频展示

前端页面我用了比较朴素但实用的三栏布局：左侧是视频监控区，视频流直接播放本地摄像头画面，同时可以在这个画面用Canvas把后端返回的人脸框和关键点绘制上去；中间是状态指示区，用一个大大的圆环或色块显示当前疲劳等级（正常/轻度/严重），颜色从绿色切到黄色再切到红色；右侧是指标区，实时显示EAR、MAR、PERCLOS数值，底部是历史告警记录列表。

有人会问，既然浏览器已经本地播放摄像头，为什么还要把检测框叠加上去？这是因为后端返回的检测框坐标是基于上传帧的坐标系，和本地画面虽然几乎一致，但只要前端画布和视频元素尺寸不同，坐标就会偏移。所以前端要做一次坐标映射，按画布尺寸和原始帧尺寸的比例换算再绘制。这个映射很多新手会漏掉，导致检测框画在脸上但位置全偏。

前端核心代码片段：

javascript复制const socket = io();

socket.on("detection_result", (result) => {
  // 更新状态指示区
  document.getElementById("fatigue-level").textContent = result.level;
  currentLevel = result.level;

  // 在Canvas上绘制人脸框和关键点
  drawFaceBox(result.box);      // result.box 是 [x, y, w, h]
  drawLandmarks(result.points); // 关键点数组
  updateMetrics(result.ear, result.mar, result.perclos);
});

function drawFaceBox(box) {
  const ctx = overlayCanvas.getContext("2d");
  ctx.clearRect(0, 0, width, height);
  const scaleX = width / frameWidth;
  const scaleY = height / frameHeight;
  ctx.strokeStyle = "#00FF00";
  ctx.lineWidth = 2;
  ctx.strokeRect(box[0] * scaleX, box[1] * scaleY, box[2] * scaleX, box[3] * scaleY);
}

这里建议用Canvas而不是直接操作DOM元素来显示检测框，因为帧率高时频繁改DOM样式会导致页面重排，性能很差。Canvas的2D绘制开销很低，完全能承受10FPS的刷新。

4.2 实时告警与声音提示

告警分两个层级：视觉告警和听觉告警。视觉上，当疲劳等级变化时，整个状态区的背景会闪烁，红色告警时页面顶部弹出横幅，同时"建议停车休息"的文字显眼提示。听觉上，我在没有引入任何音频文件的情况下用Web Audio API动态生成蜂鸣声，这个做法很方便，不用打包音频资源，代码也简洁。

javascript复制function playAlertBeep() {
  const audioCtx = new (window.AudioContext || window.webkitAudioContext)();
  const oscillator = audioCtx.createOscillator();
  const gainNode = audioCtx.createGain();
  oscillator.connect(gainNode);
  gainNode.connect(audioCtx.destination);
  oscillator.frequency.value = 800;   // 人耳敏感频段
  oscillator.type = "square";
  gainNode.gain.setValueAtTime(0.3, audioCtx.currentTime);
  gainNode.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime + 1);
  oscillator.start(audioCtx.currentTime);
  oscillator.stop(audioCtx.currentTime + 1);
}

在告警判断逻辑上，我加了一个"冷却时间"机制。一次告警之后，至少30秒内不重复触发相同等级的告警，否则驾驶员被反复报警会烦躁，而且系统连续告警说明已经失去警示作用。前端收到告警事件后，把告警记录推入右侧列表，格式包含时间、疲劳等级、EAR数值、PERCLOS数值，方便事后复盘。

4.3 阈值配置与现场可调性

前端加了一个非常关键的设置面板，把EAR阈值、MAR阈值、PERCLOS告警阈值、告警冷却时间等全部暴露成可调参数。通过SocketIO发送给后端，后端实时更新检测器里的参数对象。这个设计源于我踩过的一个坑：最初阈值写死在Python代码里，现场演示时光线和测试者不同，误报频繁，只能改代码重启服务，非常尴尬。后来把阈值参数做成动态配置，现场直接用网页调，不用动代码，省了大量时间。

前端设置面板对应的SocketIO事件：

javascript复制function updateThresholds() {
  const config = {
    ear_threshold: document.getElementById("ear-threshold").value,
    mar_threshold: document.getElementById("mar-threshold").value,
    perclos_alert: document.getElementById("perclos-alert").value,
    cooldown_seconds: document.getElementById("cooldown-seconds").value
  };
  socket.emit("update_thresholds", config);
}

后端收到后更新全局配置对象，同时最好把配置持久化到一个本地JSON文件，避免服务重启后所有调参白费。

5. 常见问题与排查技巧实录

5.1 视频卡顿与延迟过高怎么排查

这个是最常见也最让人头疼的问题。实测中卡顿源我分成三个层级来查。第一层是前端上传频率过高，每帧都要压缩上传，base64膨胀加打包解码，网络消耗大，我后来固定到10FPS，画质用0.7压缩比，卡顿明显缓解。第二层是推理耗时过长，如果模型选了s或m版本，在无GPU的机器上单帧可能要100毫秒以上，前端就会感觉画面更新很慢。解决办法是换轻量模型、降低推理分辨率到320或416、开启半精度推理。第三层是前端渲染瓶颈，如果检测框绘制用的是DOM节点方式，每秒更新几十次会导致页面重排，换成Canvas后显著改善。

还有一个隐蔽的坑：SocketIO每次emit都会携带事件名和数据，如果每帧都推送大量点坐标和指标，事件本身的解析开销也会累加。我后来把关键点坐标从浮点数数组先量化成整数，一次事件就少传了很多字节。再配合跳帧策略，5到10FPS的推送频率下，浏览器端体验很顺滑。

5.2 误报和漏报问题怎么解决

误报的根源往往是阈值不合理或者环境太复杂。逆光时人脸过暗，关键点容易飞点，EAR数值忽高忽低；驾驶员戴着墨镜，眼睛被遮挡，关键点模型直接把墨镜边缘当成了眼睛轮廓。处理办法有几个方向：输入侧做图像预处理，提升暗部亮度；检测侧提高人脸置信度阈值，避免把模糊人脸纳入计算；判定侧不要只用EAR，把PERCLOS作为主指标，EAR只作为单帧状态，这样单帧飞点的干扰会被时间窗口平滑掉。

漏报更危险，说明真正疲劳了系统没发现。主要原因是测试者的脸型、头部姿态变化超出了模型范围。我在项目中加了一个头肩区域检测作为辅助——当检测不到人脸时，不立即判定为"无人"，而是维持最后一帧状态并启动计时，如果连续几秒都检测不到人脸，才判定为"脱离监控"。这个逻辑避免驾驶员低头、转头时系统直接罢工，同时也为下一步加入驾姿检测留下接口。

5.3 部署与稳定性注意事项

项目在开发环境跑通之后，生产部署还有几个坎。首先是socketio.run自带的开发服务器不适合并发场景，我用的是gunicorn配合eventlet worker，启动命令大致是gunicorn -k eventlet -w 1 --threads 8 app:app。注意这里worker数不能随便调大，因为模型推理本身是CPU/GPU密集任务，多个worker意味着多份模型副本，显存或内存容易爆。实际部署时我固定在单worker多线程模式。

其次是摄像头权限问题。浏览器调用getUserMedia需要安全上下文，也就是HTTPS或localhost。局域网内用IP访问时，浏览器会拒绝摄像权限。解决办法有两个：给后端加自签名HTTPS证书，或者在浏览器里手动添加该IP的权限例外。我在局域网演示时直接用后者，最省事。但如果你要做成产品，该上HTTPS还是得早点上。

最后是模型内存泄漏问题。YOLO推理库在循环中偶尔会产生隐性缓存，长时间运行内存上涨。我写了一个简单的健康检查接口，每半小时记录一次内存占用，如果超过设定阈值就自动重启服务进程。这个土办法在很多生产项目里都验证过，虽然不优雅，但能保证系统连续跑几天不挂。

还有一点关于日志。SocketIO的事件收发如果只在出错时打印，出了问题很不好定位。我在关键节点都加了带时间戳的日志，比如"收到帧 帧大小 推理耗时"，这样回看日志时能还原整条时序，排查究竟是哪一段流程拖慢的。别小看这个习惯，现场调试时它能帮你省下大量时间。

我自己把整套平台反复跑了几个迭代之后，最大的体会是：疲劳检测这种偏安防性质的应用，永远不要把单一模型的判断当成绝对结论。YOLO输出的只是视觉线索，EAR和PERCLOS也只是间接指标，它们都有各自的失效模式。真正稳定可靠的产品，应当在视觉判定的基础上叠加更多维度的信号，比如方向盘操作频率、车道偏移情况，甚至驾驶员的手部行为，这些信号相互印证，才能降低误报和漏报。如果你打算在这个项目上继续扩展，我的建议是先跑通当前这套端到端流程，把日志和阈值校准机制留好，再逐步接入更多的传感器数据。我也相信，把这些细节打磨到位之后，这套平台不只停留在demo阶段，它是有潜力往真实产品方向生长的。