因为maxsize只在put()时阻塞，但item引用未释放，生产者仍持续创建对象；需主动退避（如sleep或wait_for超时）而非依赖队列自动限流。
asyncio.Queue满了但内存还在涨，为什么？
因为maxsize只在put()调用时触发阻塞，而生产者如果没做超时或异常处理，协程会一直挂起在await queue.put(item)上——此时item仍被局部变量引用，没被释放，缓冲区实际已开始膨胀。Python 3.12+ 中这个现象更明显：put()阻塞期间不入队，但对象引用一直存在。
常见错误现象包括：
- 队列
qsize()稳定在maxsize，但进程RSS内存持续上升 -
queue.full()返回True后，生产者仍不断创建新对象（比如解析JSON、解码二进制） - 消费者卡在数据库慢查询或LLM调用上，
get()变慢，但生产者还在疯狂put()
关键点：阻塞 ≠ 释放。必须让生产者主动退避，而不是依赖队列自动“拦住”。
怎么让生产者感知下游速度并主动减速？
纯async for或无条件await queue.put()是拉模式，无法反压；得改成推模式 + 可取消的等待。核心不是等队列满，而是提前干预节奏。
实操建议：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 用
if queue.qsize() > threshold: await asyncio.sleep(0.001)代替直接put()——注意别用time.sleep，它会阻塞整个事件循环 - 配合
asyncio.wait_for(queue.put(item), timeout=2.0)，超时就丢弃或降级，避免无限挂起 - 用
asyncio.Event让消费者处理完一批后event.set()，生产者await event.wait()再继续，适合批处理场景 - 避免在生成器里调
await queue.join()——这是完成语义，不是流控信号，容易卡死
aiohttp或aiomisc流式响应怎么插入手动背压？
HTTP层的堆积常被忽略：客户端网络慢时，response.write(data)写入的是内核socket buffer，Python层看不到压力，但内存照涨。这不是队列问题，是传输层反压缺失。
正确做法：
- 对
aiohttp.web.StreamResponse，每次write()后必须加await response.drain()——它会等底层buffer可写才返回，这才是真实流控点 - 禁用
Content-Length，改用chunked或HTTP/2流式响应；否则即使drain了，浏览器也可能不及时消费 - 用
aiomisc.buffered包装协程，设buffer_size=100和on_full='block'，比手写Queue更可靠，还支持'drop'策略应对突发流量 - 别依赖
client_max_size参数——它只限制请求体，对响应流完全无效
aiokafka消费堆积时，max_poll_records该设多少？
Kafka消费堆积往往不是队列满了，而是poll()拉取太快、处理太慢，导致消息在内存堆积，最终触发max_poll_interval_ms超时，消费者被踢出组——这看起来像堆积，其实是“假死”。
关键参数调整：
-
max_poll_records=10–50（别用默认500），配合fetch_max_wait_ms=100减少空轮询 - 必须设
enable_auto_commit=False，手动await consumer.commit()，确保这批全成功才推进offset - 用
asyncio.Semaphore(8)限制并发处理数，上限按DB连接池、HTTP客户端并发能力定 - 消费循环里别
for msg in messages: await process(msg)——要批量asyncio.gather(*[process(m) for m in messages], return_exceptions=True)
最易被忽略的一点：所有耗时操作（如db.insert()、http.post()）都必须带超时，否则单条失败会拖垮整批，进而引发重试风暴和分区倾斜。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
