企业官网建设流程全解析

简介：面向计算机相关专业毕业设计选题与论文写作需求，这份文档围绕基于 Python、Django 与 OpenCV 的疲劳检测系统展开，重点讨论眼动信号、人脸判断、眼睛闭合程度、眨眼频次等检测思路，并涉及 Python 编程、MySQL 数据存储及图像识别、图片分析、照片管理等系统功能模块，适合需要了解疲劳检测实现路径与论文组织方式的学生参考。压缩包内共1个docx文件，整体约1.01MB，内容以学位论文文档为主，包含摘要、目录、绪论及系统设计相关章节，便于按论文结构梳理研究背景、技术路线与功能设计。已有366人学习，可作为毕业设计前期调研、需求分析与论文框架搭建的辅助材料，也能帮助读者对照 OpenCV 人脸识别与疲劳判定方法整理实验思路和写作要点。

1. 疲劳检测为什么难在“判定”而不是“识别”

很多人第一次看疲劳检测的需求，会默认难点在人脸识别。实际运行起来才发现，人脸识别反而是整条链路里最不玄学的一段——一个 Haar 级联模型几行代码就能框出一张脸，OpenCV 把这件事做得足够成熟。真正让人反复遇到问题的是框出来之后：这一帧眼睛闭了，到底算不算疲劳？闭多久算？连续几帧才算？这套基于 Python + Django + OpenCV 的疲劳检测系统，代码量的大头其实不在视觉算法，而在把“眼睛闭合”这种像素级事实，翻译成“这个人疲劳了、这条记录该不该落进 MySQL、前端统计图该画什么”。搞懂这层翻译逻辑，才搞懂疲劳检测系统为什么长成现在这样。

2. OpenCV 预处理链路：每一帧到判定之间被改写了什么

摄像头拿到的是 BGR 三通道的原始矩阵，级联分类器吃的是灰度图。中间这段预处理不是可选项，它直接决定了后面判定的稳定性。原始的 OpenCV 文档里管这条链路叫“图像预处理”，落到代码上是三个连续动作：灰度化、平滑、直方图均衡化。顺序不能乱，理由下面拆。

2.1 灰度化与平滑：先丢掉颜色，再把噪声压下去

灰度化的本质是把三维的颜色信息压缩成一维的亮度。人脸检测、眼睛检测这类任务根本不关心肤色是偏黄还是偏白，只关心局部区域的梯度变化——眼睛、眉毛、鼻翼在灰度图上都有明显的边缘。三通道转单通道顺手还带来一个工程收益：后续所有卷积运算的计算量直接降到三分之一，这对一个要连续处理摄像头的系统来说差别很实在。

平滑放在灰度化之后，是因为灰度化本身不会引入噪声，但也不会消除传感器噪声。CMOS 摄像头在暗光下噪点特别明显，这些高频噪点会被后续的直方图均衡化当成“有效信号”一起放大，所以必须先把它们压掉。常见的实现思路是高斯平滑，核大小取 3×3 或 5×5。

这里有个容易被忽略的坑：论文原文写的是cvSmooth和cvEqualizeHist，这是 OpenCV 1.x 时代的 C 接口命名。在 Python 绑定（cv2）里，这两个函数已经被拆得更细——高斯平滑对应cv2.GaussianBlur，直方图均衡化对应cv2.equalizeHist，cvSmooth那个带一堆模式枚举的万能函数在 Python 侧基本不出现了。照着老论文敲cvSmooth是跑不起来的，这不是版本号问题，是 API 范式的变更。

import cv2 import numpy as np def preprocess(frame): """把一帧 BGR 图像处理成级联分类器能吃的样子""" # 1. 灰度化：三通道 -> 单通道，丢掉颜色只留亮度梯度 gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # 2. 高斯平滑：5x5 核，压掉暗光下的高频噪点 # 核越大越平滑，但边缘也会一起糊掉，5x5 是人脸检测的经验值 gray = cv2.GaussianBlur(gray, (5, 5), 0) # 3. 直方图均衡化：把挤在一小段区间里的灰度值拉开 # 注意它只做全局均衡，对局部强光/阴影无能为力 gray = cv2.equalizeHist(gray) return gray

参数上，GaussianBlur的第三个参数 sigma 传 0，OpenCV 会按核大小自动推算，一般不用手动指定。真正需要调的是核尺寸：3×3 保边缘但去噪弱，7×7 去噪强但小目标（比如远景的眼睛）容易糊成一团。这套系统面向的是近距离摄像头，5×5 是个稳妥的起点。

2.2 直方图均衡化：把光照不均的问题交给对比度处理

直方图均衡化的作用是把灰度分布从“挤在一小段”拉成“铺满 0-255”。背光场景下，人脸整体偏暗，灰度值集中在 30-80 这个窄区间，级联分类器在这么低的对比度上很难找到稳定的边缘特征，检测率会明显下降。均衡化之后，原本差 5 个灰度的两个区域可能差 30 个，边缘就出来了。

但这一步是有代价的。均衡化是全局操作，它对整张图用同一条映射曲线。如果画面里一半是窗外强光、一半是车内阴影，均衡化会把阴影区提亮的同时把强光区推到过曝，脸部反而丢失细节。这就是为什么后面判定环节不能只依赖单帧结果——光照的鲁棒性问题在这一层是解决不掉的，只能靠多帧统计来平滑。

常见的加固手段有两个。一是用 CLAHE（限制对比度的自适应直方图均衡化）替代全局均衡，cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8,8))，把图分块后各自均衡再插值，能显著缓解局部过曝。二是干脆跳过均衡化，改成对 ROI 区域单独做归一化。论文里写的是全局cvEqualizeHist，这是教科书式的最小实现，理解它的失效边界比记住它的调用方式更有价值。

2.3 级联检测与 ROI：为什么先找人脸再找眼睛

眼睛检测的搜索范围如果铺满整张 640×480 的图，误检率会高得离谱——任何一个明暗对比强烈的角落都可能被误判成眼睛。级联分类器的设计本身就鼓励分两步走：先用haarcascade_frontalface_default.xml框出人脸，再把人脸框的上半部分切出来当 ROI，在这个小区域里跑haarcascade_eye.xml。

# 加载预训练级联模型，这两个 xml 随 OpenCV 安装包一起分发 face_cascade = cv2.CascadeClassifier( cv2.data.haarcascades + 'haarcascade_frontalface_default.xml') eye_cascade = cv2.CascadeClassifier( cv2.data.haarcascades + 'haarcascade_eye.xml') def detect_face_and_eyes(gray): # scaleFactor=1.1：每次把搜索窗口放大 10%，越小越慢但越不易漏 # minNeighbors=5：一个候选框要被 5 个邻居框投票认可才保留，压误检 # minSize=(80,80)：小于这个尺寸的人脸直接忽略，挡掉远景噪点 faces = face_cascade.detectMultiScale( gray, scaleFactor=1.1, minNeighbors=5, minSize=(80, 80)) result = [] for (x, y, w, h) in faces: # 只取人脸框的上半部分做眼睛 ROI，下半部分是嘴，会干扰检测 roi_gray = gray[y:y + h // 2, x:x + w] eyes = eye_cascade.detectMultiScale( roi_gray, scaleFactor=1.1, minNeighbors=10, minSize=(15, 15)) result.append({'face': (x, y, w, h), 'eyes': eyes}) return result

minNeighbors是控制误检和漏检之间平衡的关键参数。人脸用 5，眼睛用 10——眼睛的搜索空间更小、候选框更密，阈值不放高会出现一堆重叠框。scaleFactor取 1.1 是速度和召回折中，调到 1.05 检测更全但耗时翻倍，对实时摄像头来说不划算。

这里有个设计上的关键点值得单独说：当 ROI 里检测不到眼睛时，很多实现会直接判定为“闭眼”。逻辑上讲得通——眼睛睁着就应该能被检测到。但这个推断有个隐含前提：检测器在这个光照、这个角度、这张脸上是可靠的。戴眼镜、侧脸、刘海遮挡都会让检测器返回空，此时判定“闭眼”就是纯误报。后面第 5 章会专门讨论这个问题的规避方式。这套系统的字段设计里，眼睛状态是一个独立的eyes字段而不是直接并入pilaov，本质上是把“检测事实”和“疲劳结论”解耦——中间这层留白，就是为了让误判可回溯。

3. 从眼睛状态到疲劳结论：阈值、频次与状态机的合成逻辑

单帧的眼睛开合状态只是一个瞬时观测，它离“疲劳”这个概念还隔着两层：时间维度上的累积，以及多种表征的融合。这一步是整个系统里最像“玄学”的部分，因为它没有标准答案，只有工程上够用的经验值。

3.1 PERCLOS：为什么“闭眼时长占比”比“闭眼瞬间”更有信息量

人正常眨眼一次大概 100-400 毫秒，如果系统按 15fps 采样，一次正常眨眼会命中 2-6 帧。你要是在这 2-6 帧里判疲劳，那所有人都是疲劳的。所以判定必须落在“时间占比”上，而不是“是否出现”。

PERCLOS（Percentage of Eyelid Closure over the Pupil over Time）是这个领域最经典的指标，定义是单位时间内眼睛闭合程度超过某个阈值的帧数占比。工程上常用的简化版本是 P80：把眼睛闭合面积超过 80% 视为“闭合”，统计一个时间窗内闭合帧的比例。清醒状态下这个值通常在 0.05-0.15 之间波动，超过 0.3 就进入了明显的疲劳区间。

它的信息量来自一个生理事实：疲劳时人的眨眼模式会从“短促高频”变成“缓慢、不完全睁开的长闭眼”，单次闭眼时长可能拉到 500 毫秒以上，同时伴随微睡眠（microsleep）。这种变化在瞬时帧上看不出来，只有在时间窗口内统计占比才会凸显。所以实现上必须维护一个滑动窗口，而不是逐帧独立判断。

论文里没有明写 PERCLOS 这个术语，描述的是“眼睛闭合程度 + 眨眼频次”，本质上是同一套思路的朴素版。常见的实现思路是用一个固定长度的队列存最近 N 帧的眼睛状态，N 对应大约 30 秒的窗口，每次新帧入队、旧帧出队，实时算占比。

3.2 把眨眼频次和打哈欠合成一个“是否疲劳”字段

眼睛之外，这套系统还引入了两个辅助信号：眨眼频次和打哈欠。它们的价值不在于单独定论，而在于交叉验证。

眨眼频次的正常区间大致是每分钟 15-20 次。疲劳初期会出现代偿性的频次升高，进入深度疲劳后反而会降低并伴随长闭眼。所以它不能作为单调指标，只能作为趋势参考。打哈欠的检测靠嘴部的纵横比（Mar Aspect Ratio，MAR）——正常说话时嘴部高度和宽度比在 0.2 左右，打哈欠会拉到 0.6 以上并持续 1 秒以上。

融合逻辑写出来不复杂，但要清楚每一条的优先级：

def judge_fatigue(eye_states, mouth_states, window_frames=450): """ eye_states: 布尔队列，True 表示该帧眼睛闭合 mouth_states: 布尔队列，True 表示该帧检测到张嘴 window_frames: 约 30 秒 @15fps """ if len(eye_states) < window_frames // 10: return 'unknown' # 样本太少，不下结论，避免刚开摄像头就报警 # 主判据：闭眼帧占比，0.3 是疲劳分界 perclos = sum(eye_states) / len(eye_states) # 辅判据：打哈欠占比，阈值明显高于眼睛，因为说话也会被误判 yawn_ratio = sum(mouth_states) / len(mouth_states) # 硬规则优先：只要一项越过高位线，直接判疲劳 if perclos >= 0.3: return '疲劳' if yawn_ratio >= 0.15: return '疲劳' # 软规则：占比不高但持续闭眼，判轻度 if perclos >= 0.18: return '轻度疲劳' return '正常'

注意第一个分支return 'unknown'。这个分支在论文的流程描述里没有，但它很关键：系统刚启动时窗口是空的，样本不足就下结论是纯粹的误报源。我一般会把它当成一条铁律——任何基于统计占比的判定，都必须在样本量达到下限之后才允许输出。

另外，这里用的是“硬规则优先”而不是加权打分求和。加权求和看起来更“科学”，但权重没有可解释的来源，调试时一旦结果不对就完全无从下手。硬规则的问题是边界生硬，好处是每一条误判都能追到具体是哪条规则触发的。对一个需要交付、需要写进论文里说明的系统来说，可解释性比理论优雅重要得多。

3.3 结果落库：一张照片表承载了哪些语义

判定结果最终要变成一行行可查询的记录。这套系统的照片表设计得很朴素，但每个字段都对应着链路上的一环：

CREATE TABLE photo_info ( picid VARCHAR(32) NOT NULL, -- 主键，通常用 UUID 而非自增 picname VARCHAR(50) NOT NULL, -- 原始文件名，用于溯源 eyes VARCHAR(50) NOT NULL, -- 眼睛状态，存描述文本而非布尔值 haqian VARCHAR(2) NOT NULL, -- 是否打哈欠，Y/N pilaov VARCHAR(2) NOT NULL, -- 是否疲劳，Y/N addtime VARCHAR(20) NOT NULL, -- 创建时间，字符串形式 PRIMARY KEY (picid) );

几个设计点值得多看一眼。picid用VARCHAR(32)存 UUID 而不是用自增整数，原因是照片可能来自多个上传入口，自增主键在并发插入时容易成为瓶颈，UUID 在应用层生成就能避开这个竞争。addtime存VARCHAR(20)而不是时间戳类型，是为了方便直接按字符串做区间查询和前端展示，代价是失去了数据库层面的时间运算能力——这是典型的“用存储灵活性换查询能力”的取舍。

eyes字段留了 50 个字符存文本，而不是一个布尔值。这个选择让字段从“眼睛是否闭合”升级成了“眼睛状态的描述”，可以塞进“睁眼/闭眼/未检测到”三种取值。未检测到”这个状态能不能表达出来，直接决定了这套系统的误判能不能被事后排查。如果只有一个布尔位，你永远分不清是“真的闭眼了”还是“检测器根本没工作”。

pilaov和haqian用VARCHAR(2)存 Y/N 而不是TINYINT，主要是照顾前端和导出报表时的可读性，属于弱类型设计的典型痕迹。对单机量级的系统来说这没问题，但一旦数据量上来、需要做条件聚合，字符串比较的性能劣势就会暴露。

4. Django 侧的骨架：识别、分析、管理为什么被拆成三段

视觉逻辑和 Web 逻辑混在一起，是这类毕设系统最常见的结构问题。混在一起写能跑通，但改一个检测参数要重新理解整个视图函数，加一个统计维度要动检测代码。这套系统把它拆成图片识别、照片分析、照片管理三个模块，本质上是按“数据生命周期”分层，而不是按页面分。

4.1 请求链路：上传、识别、回写数据库的时序

一次完整的检测请求会穿过四层：浏览器拍照或选图上传 → Django 视图接收InMemoryUploadedFile→ 解码成 OpenCV 能处理的 numpy 数组 → 跑检测、算判定、写 MySQL → 返回 JSON 给前端渲染。

这里是第一个容易被忽略的细节：上传进来的文件流不能直接喂给cv2.imdecode，得先读成字节流再解码。对摄像头抓拍的 base64 数据，还要先剥掉data:image/jpeg;base64,这个前缀，否则解码返回None，后面所有步骤全部静默失败。

import base64 import numpy as np import cv2 from django.http import JsonResponse from .models import PhotoInfo from .detector import preprocess, detect_face_and_eyes, judge_fatigue def detect_view(request): if request.method != 'POST': return JsonResponse({'code': 405, 'msg': 'method not allowed'}) raw = request.POST.get('image', '') # base64 抓拍数据带前缀，不剥掉 imdecode 会返回 None if ',' in raw: raw = raw.split(',', 1)[1] try: img_bytes = base64.b64decode(raw) frame = cv2.imdecode( np.frombuffer(img_bytes, np.uint8), cv2.IMREAD_COLOR) except Exception: return JsonResponse({'code': 400, 'msg': '图像解码失败'}) if frame is None: return JsonResponse({'code': 400, 'msg': '不是有效图像'}) gray = preprocess(frame) faces = detect_face_and_eyes(gray) # 检测不到人脸时不写库，避免污染统计口径 if not faces: return JsonResponse({'code': 200, 'data': {'status': '未检测到人脸'}}) eye_closed = len(faces[0]['eyes']) == 0 record = PhotoInfo.objects.create( picname=request.POST.get('filename', 'capture.jpg'), eyes='闭眼' if eye_closed else '睁眼', haqian='N', pilaov='N', # 单帧不下疲劳结论，留给窗口判定回填 addtime=time.strftime('%Y-%m-%d %H:%M:%S'), ) return JsonResponse({'code': 200, 'data': {'picid': record.picid}})

这段代码里最关键的其实是pilaov='N'那一行注释。单帧请求只负责采集和落库，疲劳结论由窗口判定异步回填或者在下一次统计时计算。这个设计让“实时识别”和“疲劳判定”解耦——前者要求低延迟，后者要求足够的时间窗口，两者的性能诉求完全不同，硬塞进一个请求里只会两头不讨好。

4.2 分层：为什么把 OpenCV 挡在视图之外

detector.py这个模块的存在，是为了让视图函数完全不知道 OpenCV 的存在。视图只调用preprocess、detect_face_and_eyes、judge_fatigue三个函数，参数和返回值都是普通 Python 类型（numpy 数组、字典、字符串），没有任何cv2的类型泄露出去。

这么做有三个实际收益。第一是可测试性——检测逻辑可以脱离 Django 单独跑单元测试，构造一组固定图片验证判定结果，不需要起服务、不需要建数据库。第二是可替换性——哪天要把 Haar 换成基于 EAR 的关键点检测，只改detector.py内部，视图一行不动。第三是调试成本——视觉算法出问题时，问题域被限制在一个文件里，不用在几千行的视图里翻找。

常见的反面写法是把cv2.imread、detectMultiScale直接铺在视图函数里，中间穿插数据库操作和权限判断。这样写在上手阶段快，但一旦检测结果不对，你要同时排查三件事：图像解码对不对、检测参数合不合适、数据库写进去的是不是你以为的那条。这三件事混在同一个调用栈里，排查成本会成倍上升。

4.3 统计图表的数据来源

首页的用户行为图表和分析页的柱状图、饼图，看起来是前端的事，实际数据口径全在数据库层决定。

首页展示“总用户数、总图片数、当前年月、24 小时用户行为分布”，前三个是简单聚合（count()），第四个是按时段分组统计。这里有个必须提前想清楚的问题：24 小时分布是按addtime的小时切片统计，还是按用户登录时间统计？论文里没写明，但从字段设计看只能是前者——addtime是照片记录的创建时间，系统里并没有单独的登录日志表。这意味着所谓“24 小时行为”实质上是“24 小时上传分布”，语义上是有偏差的。

分析页的饼图展示“眼睛状态、打哈欠占比、疲劳占比”，数据源就是照片表按eyes、haqian、pilaov三个字段做GROUP BY。这里要注意pilaov字段的更新时机——如果判定逻辑是在上传时同步执行的，那所有历史记录的pilaov都是基于单帧得出的，统计出来的“疲劳占比”会严重偏高。正确做法是等时间窗口累积够了，用批量任务回填，或者干脆在查询时按时间窗口实时计算。

这两个口径问题在代码层面看不出来，只有把图表和底层数据对一遍才会暴露。这是我在读这类系统时最先检查的地方——图表好看不代表口径正确。

5. 排查：这类疲劳检测 Demo 最容易翻车的五个位置

视觉系统的问题有个共同特征：它不会报错，只会给你一个看起来合理但完全错误的答案。下面这几条是比较典型的问题位置，每条都按现象、原因、解决三层拆。

5.1 光照一变就判疲劳

现象：同一个人，白天测是“正常”，晚上开台灯再测就变成“疲劳”，人什么都没变。

原因：equalizeHist是全局均衡，暗光下人脸区域灰度整体偏低，均衡化会把噪点一起放大，级联检测器在噪点密集的区域找不到稳定的眼睛特征，返回空 ROI。而系统把“ROI 里没有眼睛”直接等同于“闭眼”，闭眼帧占比瞬间冲到高位，判定自然翻到疲劳。

解决：把“未检测到”和“闭眼”拆成两个状态，前者不进 PERCLOS 的分子也不进分母，只记录在eyes字段里。同时把全局均衡换成 CLAHE，或者对人脸 ROI 单独做归一化。这一条改完之后，夜间误报能压下去一大半。

5.2 戴眼镜、侧脸导致级联检测空返回

现象：摘了眼镜一切正常，戴上眼镜后整个检测链路基本失效，偶尔能检测到人脸但眼睛一直是空。

原因：haarcascade_eye.xml是在大量正脸、无遮挡的眼部样本上训练的，镜片反光和镜框边缘会被当成强特征参与投票，导致真正的眼睛被minNeighbors=10这个阈值筛掉。侧脸同理，正脸级联对旋转超过 30 度的脸几乎没有召回。

解决：眼睛检测这一步把minNeighbors降到 5-6 并允许小的误检，把判断权交给后面的时间窗口统计——单帧多几个假眼不会影响占比趋势，但整段检测不到眼睛会直接把结论带偏。对侧脸，要么加一个头部姿态的粗判并把侧脸帧标记为“不可信”跳过，要么在采集端用提示语引导用户摆正。

5.3 单帧判定与阈值抖动

现象：连续抓拍十张，结论在“正常”和“疲劳”之间反复横跳，没有稳定输出。

原因：判定基于单帧，而单帧的眼睛开合本身就是一个高频抖动的信号——人在正常眨眼时，每一帧的状态都可能翻转。用一个抖动信号去做阈值判断，结果必然在阈值附近震荡。

解决：判定必须建立在滑动窗口上，window_frames至少覆盖 30 秒。窗口内的状态用量化后的占比而不是原始帧数，且给结论加一个滞回区间——从“正常”进入“疲劳”用 0.3 的阈值，从“疲劳”退回“正常”用 0.2，中间这段保持原状态。这一条是让输出稳定下来的关键，比调任何检测参数都有效。

5.4 上传图片与摄像头帧的分辨率不一致

现象：用摄像头实时抓拍判定准确，上传本地照片就经常判错。

原因：摄像头的输出分辨率由cap.set固定，检测参数（minSize=(80,80)、minSize=(15,15)）是针对这个分辨率调出来的。上传的照片可能是 4000×3000 的原图，人脸在像素上大了十倍，minSize形同虚设，scaleFactor的搜索步长也变得不合适，要么漏检要么误检一堆。

解决：在预处理入口统一做一次缩放，把长边缩到 640 左右再做检测。缩放要在灰度化之后、平滑之前做，避免平滑核在原始大图上相对过小。这一条改完之后，所谓“实时准、上传不准”的差异基本会消失。

5.5 数据库字段长度不够吞掉结果

现象：检测日志显示判定为“疲劳”，但照片管理页面里对应的记录显示“正常”。

原因：eyes字段VARCHAR(50)、pilaov字段VARCHAR(2)。如果代码往pilaov里写了超过 2 个字符的值（比如写成“疲劳”两个字而不是“Y”），MySQL 在非严格模式下会静默截断成空串或者前两个字符，写进去的和你想存的不是一个东西，读出来自然对不上。

解决：把字段类型和写入值严格对齐，VARCHAR(2)就只写Y/N，要存中文描述就改字段长度。更稳妥的是在 Model 层加choices约束，让非法的枚举值在应用层就被拦下，而不是等到入库时被数据库悄悄改写。这类问题最消耗排查时间——链路每一段单看都正常，只有端到端对一遍才会发现对不上。

6. 设计取舍：为什么这套方案选“轻”而不是“准”

把整套系统的技术选型摊开看，它做的每一个选择都在往“轻”的方向走：用 Haar 级联而不是基于深度学习的关键点检测，用 PERCLOS 的简化版而不是完整的 P80 曲线，用单表存储而不是分表加索引，用 Django 自带 ORM 而不是手写查询优化。这套组合的准确率显然打不过任何一个现代方案，但它有一个别的东西替代不了的优势——整条链路在普通笔记本上就能跑起来，没有 GPU 依赖，没有模型下载，没有推理框架版本冲突。

这张表里我特意加了“可解释性”一行。对交付型系统来说，它的权重往往被低估——用户看到“疲劳”这个结论，第一反应是“凭什么”。视觉方案能答上来：因为你在最近 30 秒里闭眼帧占了 34%，且检测到你连续打了两次哈欠，这些都在照片记录里能翻到。深度学习方案通常答不上来，只能给一个概率值。这不是技术先进性的问题，是使用场景的问题。

我想强调的取舍点在于：疲劳检测的准确性瓶颈从来不在算法，而在判定口径。你把 Haar 换成 68 个关键点的模型，单帧的闭眼判断会准很多，但“闭眼时长占比超过多少算疲劳”这个问题，换模型是解决不了的。反过来，如果窗口设计、滞回区间、未检测状态的区分都做对了，用 Haar 也能得到一个稳定可用的输出。这套源码的价值恰恰在这里——它把判定逻辑完整地摆在明面上，每个阈值都能改、每处判断都能追，这对理解疲劳检测到底怎么回事，比直接上一套黑盒模型有用得多。

我早期做类似的东西时，习惯性地先想着换更强的检测器，折腾半个月才发现瓶颈在后面那几十行判定代码上。从那以后我每次碰这类需求，都强制先把判定链路的字段和状态机画出来，再去动视觉那一层——顺序反过来，基本就是白干。希望帮到你。

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