flask流式响应需用response包裹生成器并设direct_passthrough=true，禁用nginx/gunicorn缓冲，视频流须配对content-type与http range，mjpeg用multipart/x-mixed-replace，避免time.sleep阻塞worker。

Flask 用 Response 包裹生成器返回流数据，本质是让客户端持续接收 chunk

Flask 默认把视图函数的返回值全量渲染完才发给浏览器，而视频流、大文件下载或实时日志这类场景需要边生成边发。关键不是“用不用 yield”，而是响应对象是否启用流式传输机制。Response 构造时传入生成器（如 generate()），并显式设置 content_type 和禁用自动缓冲（direct_passthrough=True），才能触发底层 WSGI 的逐块写入。

• yield 只在函数内部起作用，它本身不构成流响应；必须由 Response 接收该生成器并交由 Werkzeug 处理
• 若直接在视图里写 yield（不包 Response），Flask 会把它当普通迭代器转成字符串，失去流效果
• 开发时用 Flask 自带服务器没问题，但部署到 Gunicorn/Nginx 时，默认配置会缓冲响应——必须关掉 proxy_buffering off 和 uwsgi_buffering off

视频流必须设对 Content-Type 和 Content-Range，否则浏览器不识别为可播放流

单纯返回一堆字节流，浏览器不会自动调用 video 标签解码。真实视频流（如 MP4 片段）需要模拟 HTTP Range 请求行为，返回 206 Partial Content 和正确头信息，否则 <video></video> 标签加载失败或卡在 loading 状态。

• 不要用 text/plain 或空 Content-Type 返回视频二进制；MP4 必须是 video/mp4，WebM 是 video/webm
• 如果做简单 demo（比如用 OpenCV 实时推帧），可用 MJPEG：multipart/x-mixed-replace; boundary=frame，每帧以 --frame\r\nContent-Type: image/jpeg\r\n\r\n[bytes]\r\n 格式拼接
• 浏览器发起的首次请求通常是无 range 的，服务端应返回 200 OK + 完整头部；后续 seek 才走 206，需解析 Range 请求头并计算偏移

生成器函数里别用 time.sleep() 控制帧率，会阻塞整个 worker 进程

Flask 开发服务器默认单线程，Gunicorn 默认同步 worker 模式也是每请求独占一个进程/线程。在 generate() 里写 time.sleep(0.03)（对应 30fps），等于让这个 worker 在 30ms 内无法处理其他请求，高并发下直接雪崩。

• 真要控帧率，得用非阻塞方式：比如用 generator.send() 配合事件循环，或改用 async def + AsyncGenerator（需 Flask 2.3+ 和 ASGI 服务器如 Uvicorn）
• 更实际的做法是靠客户端控制节奏：服务端尽可能快地 yield 帧，前端用 requestAnimationFrame 或 setTimeout 控制绘制频率
• OpenCV 的 cap.read() 本身有 IO 延迟，已隐含一定间隔，额外 sleep 往往多余

本地测试能跑 ≠ 生产能用，Nginx 默认吃掉 Transfer-Encoding: chunked

Flask 用生成器返回流时，底层靠 Transfer-Encoding: chunked 分块传输。但 Nginx 默认会等整个响应结束才转发，相当于把流“攒起来”再发，彻底破坏流式语义。

• 必须在 location 块中加：proxy_buffering off;、proxy_cache off;、chunked_transfer_encoding on;
• 如果用了 HTTPS，还要确认 SSL buffer 设置没干扰（如 ssl_buffer_size 4k 可能导致小 chunk 合并）
• 验证是否生效：用 curl -i http://yourdomain/video 看响应头有没有 Transfer-Encoding: chunked，且 body 是分段出现而非一次性刷出

流式返回最麻烦的从来不是怎么写生成器，而是每一层中间件（WSGI server、反向代理、浏览器缓存）都在默默把你精心设计的流切成块、缓存、重排序。调通一个点，不代表整条链路畅通。