简介面向高校毕业设计、课程设计的智慧养老系统完整工程包基于Python、OpenCV、Web与FFmpeg技术栈构建。系统借助多路摄像头模拟真实环境利用计算机视觉算法实时分析老人表情、跌倒、闯入禁区、义工互动并识别陌生人且持续追踪所有异常事件自动写入数据库并同步刷新到管理报表便于管理人员快速响应。压缩包共1078个文件、约316.77MB内容涵盖Python源码、Vue前端页面、视觉算法模块FaceNet、Mini-Xception、OpenPose等、预训练模型、基于Nginx-RTMP的直播推流配置以及答辩PPT和项目文档。另有css、js等前端资源及部分编译中间产物目录按功能模块划分结构清晰易查。已有237人学习下载适合需要完整可运行方案的高年级本科生或研究生既可直接部署演示也可对老人表情识别、摔倒检测等环节做二次开发还可作为毕业设计答辩的支撑材料。1. 为什么智慧养老系统值得用 Python OpenCV Web FFmpeg 做一次完整落地一个做课程设计或毕业设计的学生、或者想给家里老人做点实用工具的开发者往往会被“智慧养老”这个名字唬住以为门槛极高。实际上把任务拆开看核心就三件事用摄像头看护老人、识别异常行为最常见的是跌倒、把结果推送到一个能看的 Web 页面。这里面最重的算法环节由 OpenCV 承担视频流传输交给 FFmpeg业务展示层用 Web 框架组织起来而 Python 把三者粘合在一起。这个组合不是凭空拼凑而是每一层都恰好有成熟的开源方案能在几周内做出一个能答辩、能演示、能真正运行的完整系统。我见过很多同学的毕业设计翻车不是死在算法上而是死在工程集成上模型在本地跑通了却不知道怎么把视频流推到浏览器摔倒检测的阈值调了一周最后还是误报满天飞。这篇文章就顺着“从摄像头到浏览器”的链路把每一层怎么选、怎么搭、参数怎么设、坑在哪里都拆开讲。如果你是要做毕业设计或者课程设计的计算机相关专业学生这篇文章可以当作你的落地手册如果你是想给家里老人做一套看护系统的开发者同样适用。全文不依赖特定硬件一个普通 USB 摄像头加一台普通电脑就能跑起来。2. 技术选型为什么是这四个组件而不是更重的方案2.1 OpenCV 在智慧养老里的定位不是训练模型而是处理视频帧很多人一听到计算机视觉第一反应是深度学习、训练模型。但在智慧养老这个场景里尤其是课程设计和毕业设计的时间预算下OpenCV 的传统图像处理手段往往比训练一个神经网络更可靠、更可控。跌倒检测本质上是检测“人的姿态发生剧烈变化且不再恢复”这个任务不需要识别老人是谁、不需要区分老人穿什么衣服只需要关注轮廓、位置、运动速度这几个维度的变化。OpenCV 在这里承担的是视频解码后的帧处理工作背景建模、前景提取、轮廓检测、形态学去噪、目标跟踪。这些操作在 CPU 上就能跑得动不需要 GPU。我一般用 OpenCV 的 BackgroundSubtractorMOG2 做前景分割配合 contour 拿到人体外接矩形再从外接矩形的宽高比、面积变化率和重心下降速度三个特征去判断是否跌倒。这个方案在室内固定摄像头场景下准确率可以做到 90% 上下对于答辩演示完全够用。关键的一点是OpenCV 处理的是帧不是流。流是 FFmpeg 的事。很多新手把 OpenCV 的 VideoCapture 当成万能的流处理工具结果发现高分辨率视频或者长时间运行时内存暴涨就是因为没有理解 OpenCV 只负责“吃帧”FFmpeg 负责“搬运”。这两个组件配合起来才是完整的视频链路。2.2 FFmpeg 的角色把摄像头拉流、转码、推到 Web 端Web 页面不能直接播放原始 RTSP 流浏览器原生不支持这个协议。这就是 FFmpeg 必须存在的原因。FFmpeg 在这个系统里做三件事把摄像头的 RTSP 流转成 Web 端能播放的格式通常是 HLS 或 HTTP-FLV把本地视频文件推成直播流来模拟摄像头以及在后端对视频做切片处理。这里有一个重要的选型决策HLS 还是 HTTP-FLV。HLS 延迟在 3 到 8 秒HTTP-FLV 延迟在 1 秒以内但 HLS 对浏览器兼容性最好iPhone 也能直接看。我做系统时一般会推 HLS因为养老场景关注的是报警触发后的视频回看对实时性要求没那么苛刻3 秒延迟完全能接受。如果你要展示演示效果想看延迟更低的实时画面再改用 HTTP-FLV。FFmpeg 的命令行参数是这块最容易出错的地方。但它不需要写代码通过 subprocess 在 Python 里调用即可。后面第 4 章我会给出完整的推流命令和参数注释这里先记住一个原则FFmpeg 的错误信息是非常明确的报错时优先看 stderr 输出不要凭感觉改参数。2.3 Web 技术栈Flask 还是 Django接口怎么划分Web 层在这个系统里承担三件事用户登录和权限控制、摄像头管理、报警记录展示。同时它要能把 FFmpeg 进程管起来还要能接收 OpenCV 检测线程发来的报警消息。Flask 足够轻量适合这个项目因为整个系统只有十几个接口Django 适合要带后台管理系统的场景但重了很多对课程设计来说有点杀鸡用牛刀。我一般用 Flask Flask-SocketIO 做 Web 层。为什么加 SocketIO因为跌倒检测是异步事件检测线程发现跌倒后需要用 WebSocket 主动推给前端而不能让前端反复轮询接口。这个设计很多教程不会讲但它是系统“实时感”的关键。前端用原生 HTML JavaScript 就已经足够不需要上 Vue 或 React除非你想在答辩时展示前端工程能力。Web 层还有一个容易被忽视的职责把 OpenCV 检测线程、FFmpeg 推流进程、Flask 应用本体三者之间的生命周期协调好。后面我会给出一个简单实用的线程管理方案。3. 从零搭建智慧养老系统环境配置和跌倒检测算法实现3.1 环境搭建最小可用配置和三个必装包在开始写代码之前先把环境搭好。这个项目的依赖可以分为四组Python 基础环境、OpenCV 相关、Web 相关、FFmpeg 工具本身。我建议用虚拟环境不要直接装到全局否则后面装其他项目时容易版本冲突。python 安装教程很多核心就一句话去官网下载安装包装的时候勾选“Add Python to PATH”安装完成后在命令行里验证版本即可。# 创建虚拟环境python -m venv 是标准做法 python -m venv .venv # Windows 激活虚拟环境 .venv\Scripts\activate # Linux / macOS 激活虚拟环境 source .venv/bin/activate # 安装 Python 依赖 # opencv-python 是 OpenCV 的官方 Python 发行版 # flask 是 Web 框架flask-socketio 用于实时推送报警 pip install opencv-python flask flask-socketio flask-cors虚拟环境这一步非常关键。我遇到很多同学装 OpenCV 装出问题多半是全局环境里其他包把 numpy 版本搞乱了。OpenCV 对 numpy 版本的兼容性比较敏感尤其是老版本 OpenCV 配新 numpy 会直接 import 报错。在虚拟环境里就不用担心这些。装完 Python 依赖后验证 OpenCV 是否可用# 打印 OpenCV 版本能输出版本号就说明安装成功 python -c import cv2; print(cv2.__version__)FFmpeg 是独立于 Python 的工具。opencv 安装教程里经常会提到 FFmpeg但两者不是一个东西。FFmpeg 需要单独下载Windows 下从官网下载 release 版解压后把 bin 目录加到系统 PATH 里。注意不要下载 essentials 版以外的特殊版本除非你确定自己需要静态编译的额外功能。安装完成后验证# 打印 FFmpeg 版本注意检查输出里有没有 libx264 编码器 ffmpeg -version看到版本信息后还要确认一件事编码器是否齐全。HLS 推流需要 libx264如果你发现 ffmpeg -version 的输出列表里没有 libx264说明你下载的是精简版需要换一个带 x264 的构建版本。这是我在装 FFmpeg 下载环节踩过最普遍的坑。3.2 跌倒检测核心背景建模、轮廓提取与特征判断接下来是系统的核心跌倒检测。我不会用深度学习模型因为课程设计要讲得清原理传统图像处理的方法每一步都有直观解释答辩时更好讲。算法流程分五步背景建模、前景提取、形态学去噪、轮廓筛选、特征判定。先看完整的检测循环代码我会把每一步的注释写得足够细确保新手跟着能跑import cv2 import numpy as np import time class FallDetector: def __init__(self, min_area4000, aspect_ratio_threshold1.2, fall_score_threshold5.0, alert_cooldown3.0): # MOG2 背景建模history 是建模帧数越大对光照变化越不敏感 # varThreshold 是前景判定阈值越大前景区域越小 self.bg_subtractor cv2.createBackgroundSubtractorMOG2( history500, varThreshold25, detectShadowsTrue ) # 最小轮廓面积过滤掉噪点和宠物等小目标 self.min_area min_area # 宽高比超过该值判定为“姿态异常” self.aspect_ratio_threshold aspect_ratio_threshold # 连续帧累计的跌倒评分阈值 self.fall_score_threshold fall_score_threshold # 报警冷却时间防止重复报警 self.alert_cooldown alert_cooldown self.fall_score 0.0 self.last_alert_time 0.0 def process_frame(self, frame): # 1. 缩放帧以提高处理速度长边控制在 640 足够 h, w frame.shape[:2] scale 640 / max(h, w) frame_resized cv2.resize(frame, (int(w * scale), int(h * scale))) # 2. 背景建模提取前景 fg_mask self.bg_subtractor.apply(frame_resized) # 3. 形态学去噪先腐蚀去掉孤立噪声点再膨胀恢复主体轮廓 kernel cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (5, 5)) fg_mask cv2.morphologyEx(fg_mask, cv2.MORPH_OPEN, kernel) fg_mask cv2.dilate(fg_mask, kernel, iterations2) # 4. 轮廓提取与筛选 contours, _ cv2.findContours( fg_mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE ) fall_triggered False for contour in contours: area cv2.contourArea(contour) if area self.min_area: continue x, y, bw, bh cv2.boundingRect(contour) # 宽高比 宽度 / 高度站立时约 0.3~0.5躺平时接近 1 或超过 1 aspect_ratio bw / max(bh, 1) # 5. 特征判定宽高比异常累计 面积变化率加权 if aspect_ratio self.aspect_ratio_threshold: self.fall_score 1.0 else: self.fall_score max(0.0, self.fall_score - 0.3) # 用矩形面积占画面比例做二次确认 frame_area frame_resized.shape[0] * frame_resized.shape[1] coverage area / frame_area if self.fall_score self.fall_score_threshold and coverage 0.08: current_time time.time() if current_time - self.last_alert_time self.alert_cooldown: fall_triggered True self.last_alert_time current_time # 报警触发后重置评分避免连续触发 self.fall_score 0.0 # 在调试画面中绘制检测框 cv2.rectangle(frame_resized, (x, y), (x bw, y bh), (0, 255, 0), 2) cv2.putText(frame_resized, fAR: {aspect_ratio:.2f}, (x, y - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) return frame_resized, fg_mask, fall_triggered这段代码背后的逻辑需要多说几句。第一个关键点是宽高比这个特征人站立时轮廓的宽高比通常在 0.3 到 0.5 之间跌倒后变成平躺姿态宽高比会接近甚至超过 1。但这个特征单独使用会误报老人弯腰捡东西、坐下、躺在床上都可能让宽高比瞬间变大。所以代码里加了“累计评分”机制单帧异常计 1 分正常帧回退 0.3 分只有持续异常累计到阈值才触发报警。这个思路比单纯设一个宽高比阈值要稳得多。第二个关键点是 area 阈值和 coverage 阈值。min_area 过滤掉小猫小狗、飞虫等小目标coverage 确保目标足够大不会把远处路过的人误判为跌倒。这两个参数需要根据摄像头的安装高度和角度现场调节。第三个点是 MOG2 的 history 参数。我把 history 设为 500意味着背景建模需要约 500 帧来适应场景。如果摄像头架好后有人或者物体在画面里频繁移动背景建模会把这些运动目标吸收进背景导致漏检。标准做法是架好摄像头后先让画面空场 2 到 3 分钟再启动检测线程。3.3 读取视频流本地文件、USB 摄像头和 RTSP 流的统一封装跌倒检测算法写好后要接上视频源。这个系统的视频来源有三种已有视频文件用于演示、USB 摄像头用于现场实测、RTSP 网络摄像头用于真实场景。我建议把视频源封装成同一个接口方便切换。class VideoSource: def __init__(self, source): self.source source self.video None self.is_url isinstance(source, str) and source.startswith((rtsp://, http://)) def open(self): if self.is_url: # 网络摄像头开启 OPENCV_FFMPEG_CAPTURE_OPTIONS 来优化延迟 self.video cv2.VideoCapture(self.source, cv2.CAP_FFMPEG) # buffer_size 设小可以减少延迟但过小容易丢帧1000 起步 self.video.set(cv2.CAP_PROP_BUFFERSIZE, 1000) else: self.video cv2.VideoCapture(self.source) if not self.video.isOpened(): raise RuntimeError(f无法打开视频源: {self.source}) return self def read(self): ret, frame self.video.read() return ret, frame def release(self): if self.video: self.video.release()这里有一个值得注意的细节网络摄像头用 cv2.CAP_FFMPEG 打开这意味着 OpenCV 底层调用的是 FFmpeg 的拉流解码能力。如果这一步读取失败先不要怀疑代码回到 FFmpeg 命令行手工拉流测试确认网络和摄像头本身没问题。使用 USB 摄像头时还需要注意分辨率设置。很多 USB 摄像头默认输出 1080p但在 1080p 下做背景建模CPU 占用会显著升高而且小目标检测不一定更准。我一般会显式设置分辨率为 640x480 或 1280x720。4. 打通视频链路FFmpeg 推流到 Web 端的前后端实现4.1 后端架构检测线程、推流进程和 Flask 应用的协调现在算法有了视频源有了还差 Web 展示。这块是整个系统最考验工程能力的部分因为三个组件要在同一个 Python 进程里协作OpenCV 检测线程持续读帧和推理FFmpeg 进程负责把视频流转成 Web 可播放的格式Flask 应用对外提供接口。我直接用完整代码说明怎么组织它们import threading import subprocess import time from flask import Flask, jsonify, render_template from flask_socketio import SocketIO, emit from fall_detector import FallDetector from video_source import VideoSource app Flask(__name__) socketio SocketIO(app, cors_allowed_origins*) # 全局状态摄像头是否开启、当前报警列表 camera_state {running: False, source: None} alert_list [] # 报警记录每个元素是一个字典 {time, camera_id, image} detector FallDetector() # FFmpeg 推流命令模板把 RTSP 或本地文件转为 HLS # 注意-re 表示按原速度读取去掉它 FFmpeg 会全速处理并导出音画不同步的文件 FFMPEG_HLS [ ffmpeg, -re, -i, {input}, -c:v, libx264, -preset, ultrafast, -tune, zerolatency, -c:a, aac, -f, hls, -hls_time, 2, -hls_list_size, 5, -hls_flags, delete_segments, static/live/index.m3u8 ] class DetectionThread(threading.Thread): def run(self): video VideoSource(camera_state[source]) video.open() while camera_state[running]: ret, frame video.read() if not ret: break display, mask, fall detector.process_frame(frame) if fall: alert_time time.strftime(%Y-%m-%d %H:%M:%S) cv2.imwrite(fstatic/snapshots/{alert_time.replace(:, -)}.jpg, frame) alert_list.insert(0, {time: alert_time, camera: camera_state[source]}) socketio.emit(fall_alert, {message: alert_time}) video.release()这个线程模型的关键在于OpenCV 检测线程和 FFmpeg 推流进程都在读取同一个视频源它们是两个独立消费者。FFmpeg 有自己的缓冲机制OpenCV 的 VideoCapture 如果带缓冲也会自己积帧所以两者不会互相阻塞。但如果摄像头是 RTSP 的有些 RTSP 源只允许单路连接这时就要在 FFmpeg 和 OpenCV 之间加一层代理先让 FFmpeg 把 RTSP 拉成 HTTP 流OpenCV 再读这个 HTTP 流。常见做法是先跑一个 ffmpeg 转发进程把 RTSP 转成本地 UDP 回环地址两个消费者都去读本地地址。4.2 Web 接口和实时报警推送后端接口不需要太多但每一个都很关键。登录接口可以用简单的 token 校验不要用会话框架省掉一堆配置。摄像头控制接口要能启停检测线程。报警列表接口要返回最近的报警记录。实时推送用 SocketIO 的 emit 实现这是整个系统最有技术含量的部分。app.route(/) def index(): return render_template(index.html) app.route(/api/list_cameras) def list_cameras(): # 这里可以读配置文件返回已登记的摄像头列表 cameras [{id: 1, name: 客厅, rtsp_url: rtsp://192.168.1.100:554/stream1}] return jsonify({code: 0, data: cameras}) app.route(/api/start/int:camera_id) def start_camera(camera_id): if camera_state[running]: return jsonify({code: 1, message: 已有摄像头运行中}) # 根据 camera_id 获取 RTSP 地址这里从配置读取省略取数逻辑 camera_state[source] rtsp://user:pass192.168.1.100:554/stream1 camera_state[running] True thread DetectionThread() thread.daemon True thread.start() # 启动 FFmpeg 推流进程Popen 避免阻塞 Flask cmd [c.format(inputcamera_state[source]) for c in FFMPEG_HLS] subprocess.Popen(cmd, stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL) return jsonify({code: 0, message: 摄像头启动成功}) app.route(/api/stop) def stop_camera(): camera_state[running] False return jsonify({code: 0, message: 摄像头已停止}) app.route(/api/alerts) def get_alerts(): return jsonify({code: 0, data: alert_list[:20]}) if __name__ __main__: socketio.run(app, host0.0.0.0, port5000, debugFalse)这段代码有四个关键设计每一个都对应一个常见的坑。第一个是 DetectionThread 继承 threading.Thread并且 run 方法里用 while camera_state[running] 做循环控制而不是用 daemon 加 join 的方式硬停线程。这样 stop 接口只是改一个布尔值线程自然退出Windows 下不会出现线程无法终止的问题。第二个是 subprocess.Popen 而不是 subprocess.run。run 会阻塞 Flask 进程直到 FFmpeg 退出这会导致接口长时间卡住。Popen 是异步启动适合长时间运行的推流进程。第三个是 FFmpeg 的 stderr 被丢弃。这在调试阶段是不可取的一旦推流失败你完全不知道原因。正式开发时应该 stderrsubprocess.STDOUT 并重定向到日志文件。第四个是报警线程用 socketio.emit 而不是 HTTP 请求。如果在前端用轮询接口查报警延迟高且消耗资源WebSocket 推送是实时系统的标准做法。4.3 前端播放 HLSVideo.js 还是原生 video 标签前端播放 HLS 流需要讨论一下用不用 Video.js。方案一直接用 video 标签加 HLS 播放能力。现代浏览器 Chrome 和 Edge 原生支持 HLS其实不是Safari 才原生支持 HLSChrome 需要借助 MSEMedia Source Extensions。方案二引入 hls.js 库在 Chrome/Firefox 上实现 HLS 播放这是最通用的方案。我建议用 hls.js因为它的集成足够简单且兼容桌面端和移动端的绝大多数浏览器。引入的方式也很轻一个 script 标签搞定。video idlive-video controls autoplay muted/video script srchttps://cdn.jsdelivr.net/npm/hls.jslatest/script script const video document.getElementById(live-video); if (Hls.isSupported()) { const hls new Hls(); // 监听后端 /static/live/index.m3u8 路径 hls.loadSource(/static/live/index.m3u8); hls.attachMedia(video); hls.on(Hls.Events.MANIFEST_PARSED, () { video.play(); }); } else if (video.canPlayType(application/vnd.apple.mpegurl)) { // Safari 原生 HLS 支持 video.src /static/live/index.m3u8; video.addEventListener(loadedmetadata, () video.play()); } /script这段前端代码要配合后端的静态文件路由。Flask 默认把 static 目录映射为 /static所以 HLS 切片文件和 m3u8 索引文件放在 static/live 下即可被前端访问。注意 FFmpeg 生成切片时需要保证 index.m3u8 的路径和前端请求路径一致如果改过路径FFmpeg 命令里的 -f hls 之后的输出文件名也要对应调整。前端还有两个必须注意的点一是 muted 属性必须加上否则浏览器自动播放策略会阻止视频起播二是 autoplay 加 muted 加 playsinline 的组合是为了让移动端也能自动起播。5. 智慧养老系统的典型踩坑记录现象、原因和解决5.1 坑一本地视频能检测USB 摄像头黑屏无画面现象用视频文件做检测时一切正常换成 USB 摄像头之后画面黑屏或者 OpenCV 报 -215 错误。原因最常见的是摄像头被其他软件占用。Windows 上微信、钉钉、浏览器如果正在使用摄像头OpenCV 会拿不到设备句柄。其次是 opencv 的 VideoCapture 默认用 MSMF 后端访问 USB 摄像头MSMF 在某些摄像头型号下有兼容问题。解决先关掉所有可能占用摄像头的软件如果还不行在 VideoCapture 里显式指定后端cap cv2.VideoCapture(0, cv2.CAP_DSHOW)Windows 下用 CAP_DSHOW 的兼容性比默认的 MSMF 要好。另外在启动检测线程前加一个摄像头初始化检查isOpened() 返回 False 时直接给出中文错误提示而不是等到崩溃才发现。5.2 坑二MOG2 背景建模被空椅子干扰老人坐下后检测区间异常现象把摄像头对准客厅后画面里的沙发或椅子被建模成背景的一部分当老人坐在沙发上时轮廓不完整跌倒检测无法区分坐和躺。原因MOG2 在建模阶段会把静止不动的物体吸收为背景沙发属于背景。老人坐在沙发上时身体与沙发重叠前景区域会缩小宽高比特征也会被扭曲。解决一是调整摄像头的安装高度俯视视角比平视视角能把人椅重叠的影响降到最低二是引入深度信息用深度摄像头配合但这会提高硬件成本。在课程设计这种限定条件下我建议换个检测策略室内的摄像头一般架在墙角倾斜角在 30 到 60 度之间跌倒检测的特征不仅要看宽高比还要看重心高度变化和运动速度。重心高度可以通过轮廓的最低点和最高点估计跌倒时重心会快速下移 30% 以上。5.3 坑三FFmpeg 推流报 Unknown encoder libx264现象启动推流功能后后端日志里报错误Unknown encoder libx264HLS 文件永远没有生成。原因系统安装的 FFmpeg 是精简版没有编译 x264 编码器。FFmpeg 下载官网提供的默认 Windows 构建版本只包含很少的编码器很多版本不带 libx264。解决换一个带 x264 的构建版本或者安装 ffmpeg-full。判断方法很简单在命令行执行ffmpeg -encoders 2NUL | findstr x264如果能输出 libx264就说明可用。没有的话下载编译好的全套版本把新路径加到 PATH 最前面并重新打开终端验证。5.4 坑四HLS 流播放几秒后卡住或者画面越来越慢现象浏览器能播放直播画面但播放几秒到几十秒后画面就卡住刷新页面又恢复过一会儿再卡。原因HLS 切片和播放器的缓冲策略不匹配导致。FFmpeg 的 -hls_list_size 如果太大m3u8 里累积的切片太多而 hls.js 默认的缓存策略可能存在丢切片的兼容问题。更常见的原因是 FFmpeg 拉流的速度忽快忽慢导致切片时间戳不连续。解决把 hls_time 设为 2 秒并固定 hls_list_size 为 5这两个值匹配起来最稳。同时加上 -hls_flags delete_segments 让旧切片及时删除防止磁盘写满。如果播放器侧出现加载速度异常可以尝试用 Network 面板观察 index.m3u8 的请求间隔确认切片是否按时生成。还有一个玄学原因是防火墙拦截了 m3u8 的轮询请求如果开启了 Windows 防火墙并限制了 Python 的公网/私网权限放行即可。5.5 坑五跌倒报警不触发或者误报频率高现象老人真的摔倒了系统没有报警或者老人只是弯腰系鞋带系统狂报警。原因这两类问题都是阈值设置不合理。不报警多半是 aspect_ratio_threshold 设得太高或者 fall_score 阈值设得太高误报多半是 min_area 太小或者 cooldown 时间太短。解决调节的先后顺序有讲究。先把 cooldown 设成 5 秒以上排除连续报警的干扰。然后调 min_area在调试画面上打印出正常站立时的轮廓面积把 min_area 设成这个面积的 30% 左右。接着调宽高比让测试者在画面里做从站立到躺下的动作记录宽高比变化曲线的最大值把阈值设成这个值的 0.75 倍。最后调 fall_score 阈值。每次只改一个参数不要同时调两三个否则翻车了都不知道是哪一步引起的。所有参数建议用配置项暴露不要硬编码在代码里。6. 进阶验证和效率优化把演示做得像真的产品系统跑通基本功能后可以再加几个让答辩效果明显提升的东西。第一个是录制与回放。检测线程在触发报警时已经保存了报警瞬间的帧图片这会存在 static/snapshots 目录。进阶做法是保存报警前 10 秒的 HLS 切片让 Web 页面能回看整段视频。实现方法不复杂FFmpeg 加 -hls_flags delete_segments 并指定一个独立目录检测线程触发报警时先拷贝最近的几个切片文件再生成一个临时 m3u8 列表。我建议按这个优先级去加功能呼吸频率检测比人脸识别更实用久坐提醒比陌生人闯入更有说服力。原因很简单智慧养老的核心用户是老人和家属老人最需要的是异常状态的及时发现而不是安防级别的身份识别。第二个要优化的是 CPU 占用。OpenCV 传统算法在 640x480 分辨率下在 i5 级别的 CPU 上单线程处理大约是 20 到 30 帧每秒这完全够用。但如果开启多个摄像头CPU 会吃满。常见做法是把处理帧率限制在 10 帧每秒跌倒检测对帧率的要求不高因为在跌倒发生后 2 秒内报警体验上没有差别。限制帧率的代码很简单# 在检测线程的 while 循环里每处理 3 帧就跳过 1 帧 frame_count 1 if frame_count % 3 ! 0: continue第三个值得做的是报警去重和优先级。同一个老人如果在 5 分钟内触发了两次报警第二次的推送应该标记为“复查”而不是继续用最高优先级刺耳的提示音。这需要后端维护一个简单的报警计数 map用 camera_id 做 key。检测线程触发时递增计数查一下上一次报警时间超过设定的静默期才推送新通知。第四个是日志。我在第一版系统里没有加日志结果答辩演示时 U 盘拔掉后系统运行状态完全无从查起。后来加了一个简单的 log 模块把 FFmpeg 的 stderr、OpenCV 每一帧的处理时间、报警触发时间都写到本地日志文件。这样遇到疑难杂症时不需要靠猜打开日志按时间排序看即可。最后说一点血泪经验任何演示系统在答辩前一定要做一次“冷启动测试”。把电脑重启数据库清干净摄像头重新插上从零开始启动整个系统看能不能走到画面显示的步骤。我见过太多项目在开发机上反复调通一到答辩教室换环境就起不来最后只看到命令行报错。冷启动测试能逼你把所有绝路都提前探一遍也算给自己留一颗后悔药。整个智慧养老系统的核心价值是让异常可视、实时、可查希望这篇落地过程中踩过的坑和调参顺序能帮你少走弯路祝你的系统一次跑通。本文还有配套的精品资源点击获取