生产网关禁用 asyncio.run()，须手动管理事件循环并注册 SIGINT/SIGTERM 信号处理器以实现优雅关闭；ClientSession 必须复用而非每次新建；路由需结合健康检查与延迟加权；流式响应必须启用 streaming=True 并配置反向代理。
asyncio.run() 不能用在生产网关里
直接用 asyncio.run() 启动网关服务，进程一收到 SIGTERM 就硬退出，连接没关闭、缓存没刷、日志没落盘。生产环境必须手动管理事件循环，并注册信号处理器。
正确做法是：在主线程显式创建并运行循环，用 loop.add_signal_handler() 拦截 SIGINT 和 SIGTERM，触发 graceful shutdown 流程 —— 关闭服务器、等待活跃请求完成、释放客户端连接池（如 aiohttp.ClientSession）、最后停止循环。
- 别在子线程里调
asyncio.run()，它会新建循环，和主线程不互通 -
web.run_app()（aiohttp）或uvicorn.run()（FastAPI）底层已封装好信号处理，但你要确认它启用了lifespan或自定义on_shutdown钩子 - 若自己手写事件循环调度，务必在
signal_handler中调用loop.stop()而非直接sys.exit()
并发转发请求时，ClientSession 必须复用
每次发请求都新建 aiohttp.ClientSession 或 httpx.AsyncClient，会快速耗尽本地端口、触发 ConnectionRefusedError 或 TooManyRedirects，尤其在 QPS 过千时。
Session 是线程/协程安全的，设计初衷就是长期持有、复用底层连接池。把它做成全局单例，或通过依赖注入传入 handler，而不是在每个 async def 里 async with 一次。
立即学习“Python免费学习笔记（深入）”；
- 设置
connector = aiohttp.TCPConnector(limit=100, limit_per_host=30)控制并发连接数，避免打爆下游 - 启用
keepalive_timeout复用 TCP 连接，减少三次握手开销 - 别在
async with session.get(...)外层再套async with—— 这等于每次请求都重建连接池
智能路由不能只靠随机或轮询
真实微服务集群里，节点健康状态、响应延迟、当前负载差异很大。纯轮询会把流量压向已卡顿的实例，导致雪崩。
至少要实现「健康检查 + 延迟加权」双因子路由：定时探测各服务 /health 端点；记录最近 N 次调用的 latency；选节点时按 1 / (latency + 0.1) 加权随机，健康分归零的节点直接剔除。
- 健康检查不能阻塞主事件循环 —— 用
asyncio.create_task()启动后台探测任务 - 延迟统计用滑动窗口（如
collections.deque(maxlen=50)），避免内存无限增长 - 权重更新需加锁（
asyncio.Lock），否则并发修改导致数据错乱
流式响应（SSE/Chunked）必须用 streaming=True
LLM 网关或实时日志推送场景下，后端返回的是持续流（如 text/event-stream），若用默认的 await response.text()，会等整个响应体收完才返回，彻底失去流式意义。
必须显式启用流式读取：async for line in response.content.iter_any(): 或 response.content.iter_chunks()，边收边转发给客户端。
- FastAPI 中用
StreamingResponse包装异步生成器，别用普通JSONResponse - aiohttp 中用
response.content属性获取原始流对象，不是response.read() - 注意反向代理（如 Nginx）默认缓冲响应，需配置
proxy_buffering off和chunked_transfer_encoding on
真正难的不是并发数量，而是当 10 个服务节点中 3 个开始超时、2 个返回 503、还有 1 个悄悄丢包时，网关能否自动降级、切流、告警并保留完整 trace 上下文 —— 这些逻辑全得你用 asyncio 协程+状态机+超时控制+重试策略手工编排，没有银弹。
