Flask中唯一轻量可落地的实时视频流方案是cv2.VideoCapture+Response返回MJPEG流；不能用render_template直接显示，因浏览器无法解析cv2.Mat且不自动轮询read()，必须通过指向持续输出JPEG的Response流，mimetype须为"multipart/x-mixed-replace; boundary=frame"。
Flask 本身不支持 WebSocket 或长连接推流，直接用 cv2.VideoCapture + Response 返回 MJPEG 流是唯一轻量、可落地的方案；别碰 flask-socketio 想推帧，延迟高、易断、CPU 爆表。
为什么不能用 return render_template 直接显示摄像头画面
浏览器无法直接解析 OpenCV 的 cv2.Mat 对象，更不会自动轮询 VideoCapture.read()。常见错误是写个路由返回 HTML，但 JS 里没配 /video_feed 这个生成器路由。
- 前端必须用
- 后端该接口不能用
return jsonify(...)，必须返回Response流，mimetype="multipart/x-mixed-replace; boundary=frame" -
cv2.VideoCapture(0)在服务器无 GUI 环境（如 Linux 服务器）可能失败，需改用cv2.VideoCapture("/dev/video0")或文件路径测试
generate_frames() 函数里必须加 time.sleep(0.03)
不加限速会导致单帧处理完立刻进下一轮，CPU 占用冲到 100%，且浏览器接收帧率失控（实际远超 30fps），MJPEG 流容易卡死或触发浏览器连接重置。OpenCV 默认读帧是阻塞的，但编码和 yield 不是。
- 建议 sleep 范围：0.02～0.05 秒，对应 20～50 fps，兼顾流畅与负载
- 务必在
yield前 sleep，否则首帧延迟大；不要在while True:外 sleep - 如果用
cap.set(cv2.CAP_PROP_FPS, 15)，实际无效——多数 USB 摄像头不支持写 FPS，得靠 sleep 控制
部署时 cv2.VideoCapture 打不开设备的三个真实原因
本地跑通不代表服务器可用。典型报错是 cap.isOpened() == False 或 error: (-215:Assertion failed) size.width>0 && size.height>0 in function 'cv::imshow'（其实是 read() 返回空帧）。
- Linux 服务器没插摄像头？确认
ls /dev/video*有输出；Docker 容器要加--device=/dev/video0和--privileged - 权限问题：
usermod -a -G video $USER，然后重新登录；Ubuntu 下还可能需sudo setfacl -m u:$USER:rw /dev/video0 - 被其他进程占用：比如
motion、guvcview或另一个 Python 进程正在读，用lsof /dev/video0查
真正的难点不在拼通路，而在稳定——cap.read() 可能偶发返回 False，别假设它永远成功；cv2.imencode 可能因内存不足失败，得包 try/except；多客户端同时请求时，每个请求都新建 VideoCapture 实例会抢设备，得用全局单例 + 锁，或者干脆用 Gunicorn 启动单 worker。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
