StreamingHttpResponse为何在Django Channels ASGI下阻塞请求，WSGI下不会

• 两种运行模型的本质差异导致了阻塞问题：
  • WSGI模式下你使用的是线程型worker，每个请求占用独立的工作线程，get_stream()里的无限循环会绑定在专属线程上，不会干扰其他线程处理普通接口、后续请求。
  • ASGI+Channels的核心是单线程事件循环驱动所有任务调度：你完全保留了同步的无限流式生成器逻辑，没有做任何适配。如果该生成器被事件循环直接调度，无限循环会彻底霸占事件循环，所有HTTP请求处理、WebSocket握手/消息分发都需要等待事件循环空闲，自然全部冻结；哪怕Channels把同步逻辑扔到内置线程池，默认线程池容量有限，少量视频流请求就会占满所有线程配额，后续所有同步请求、接口全部排队无响应。

方案1：改造视频流为异步逻辑，不阻塞事件循环 #

将原同步生成器改造为原生异步实现，把阻塞的cv2操作隔离到独立线程，循环过程中主动让出事件循环调度权：

import asyncio
import cv2 as cv
from django.http import StreamingHttpResponse
from django.views.decorators.csrf import csrf_exempt

# 全局共享摄像头实例，避免每个请求重复打开摄像头占用硬件
_cap = None

def get_camera():
    global _cap
    if _cap is None:
        _cap = cv.VideoCapture(0)
    return _cap

async def get_stream():
    cap = get_camera()
    while True:
        # 把阻塞的读取、编码操作扔到独立线程执行，不占用事件循环
        ret, frame = await asyncio.to_thread(cap.read)
        if not ret:
            break
        valid, img = await asyncio.to_thread(cv.imencode, '.jpg', frame)
        yield (b'--frame\r\n'
               b'Content-Type: image/jpeg\r\n\r\n' + img.tobytes() + b'\r\n\r\n')
        # 按25帧率控制间隔，主动让出事件循环给其他任务
        await asyncio.sleep(0.04)

@csrf_exempt
async def stream(request):
    return StreamingHttpResponse(get_stream(), content_type='multipart/x-mixed-replace;boundary=frame')

方案2：保留同步代码的隔离配置 #

如果不想全量改造异步逻辑，需要做好资源隔离避免拖垮整个服务：

• 为长连接流式响应配置独立的线程池，不要和普通HTTP接口、WebSocket逻辑共用默认的同步线程池，避免长请求占满公共线程配额
• 确保ASGI运行时不会把同步流式逻辑放到事件循环线程执行，完全隔离到独立线程运行
• 调低视频流的循环频率，在生成器内加入适当的sleep间隔，减少线程被长期占有的时长

• 摄像头是硬件独占资源，不要在每个视频流请求内单独初始化cv.VideoCapture(0)，否则会出现硬件占用报错，全局复用单例摄像头即可
• 不要让视频流循环无间隔空转，根据实际需要的输出帧率设置sleep间隔，降低CPU资源占用

内容的提问来源于stack exchange，提问作者ferjif