生产部署首选 uvicorn；因其稳定性高、CVE 响应快（平均3天）、生态成熟，而 hypercorn 维护慢（CVE 平均17天）、负载不均且热重载在 Windows 下不可靠。
uvicorn 和 hypercorn 哪个更适合生产部署？
uvicorn 是当前最主流的 ASGI 服务器，实现轻量、调试友好、文档清晰；hypercorn 功能更全（原生支持 HTTP/2、gRPC over HTTP/2、多进程模式更稳定），但维护节奏慢、生态适配略滞后。生产选型不看“功能多”，而看「稳定性」和「问题响应速度」——过去一年 uvicorn 的 CVE 修复平均耗时 3 天，hypercorn 是 17 天。
-
uvicorn默认单进程 + 协程模型，适合 I/O 密集型服务；hypercorn的--workers启动方式更接近 Gunicorn 风格，但实际进程间负载不均问题更常见 -
uvicorn的--reload在开发中可靠，hypercorn的热重载在 Windows 下会卡住子进程 - 若用
Starlette或FastAPI，优先用uvicorn；若明确需要 HTTP/2 推送或 gRPC 共存，再评估hypercorn，别提前加复杂度
压测时 CPU 100% 但 QPS 上不去，是不是要换服务器？
大概率不是服务器的问题，而是 ASGI 应用本身阻塞了事件循环。ASGI 要求所有代码必须异步（或显式进线程池），但很多人把同步数据库调用、time.sleep()、requests.get() 直接写进 async def 视图里——这会让整个 event loop 卡死。
- 检查日志里是否有
RuntimeWarning: coroutine 'xxx' was never awaited，这是典型“假装异步” - 用
uvicorn --workers 1 --loop auto启动，配合py-spy record -p $(pgrep -f uvicorn)看热点函数，90% 的瓶颈在sqlite3.connect()或subprocess.run() - 不要用
asyncio.to_thread()包裹任意同步调用——它开销大，且在线程池满时会排队；对 DB 操作，该换aiosqlite或asyncpg就换
为什么本地压测 QPS 很高，上 Kubernetes 就断崖下跌？
K8s 环境下默认的 readiness probe 和连接复用策略，会悄悄杀死长连接、干扰 keep-alive 行为，导致 ASGI 服务器频繁重建连接上下文。
-
livenessProbe和readinessProbe的periodSeconds必须 ≥ 10，否则 probe 请求可能撞上正在处理的请求，触发 uvicorn 的ConnectionResetError - Ingress（如 Nginx 或 Traefik）默认禁用 HTTP/1.1 keep-alive，需显式配置
proxy_http_version 1.1和proxy_set_header Connection '' - K8s Service 的
sessionAffinity: ClientIP会干扰 uvicorn 多 worker 负载均衡，除非真需要 sticky session，否则关掉
要不要在 ASGI 前面再套一层 Gunicorn？
不要。Gunicorn 是 WSGI 时代的产物，强行用 gunicorn -k uvicorn.workers.UvicornWorker 只是叠了一层无意义的 fork+IPC 开销，还会让信号传递、日志格式、超时控制全部变复杂。
立即学习“Python免费学习笔记（深入）”；
-
uvicorn自带--workers参数（需搭配--loop auto和--http httptools），能直接管理多进程，比 Gunicorn + Uvicorn 组合更可控 - 如果依赖 Gunicorn 的配置习惯（比如
--max-requests），不如直接用uvicorn的--limit-concurrency+--timeout-keep-alive组合，效果更直接 - 唯一合理场景：已有 Gunicorn 运维体系且不允许引入新二进制——那就接受它带来的额外延迟和内存占用
真实压测中，最容易被忽略的是 ASGI 中间件的顺序和副作用。比如一个记录耗时的中间件如果放在认证中间件之后，就可能漏记失败请求；又比如 SlowAPIMiddleware 这类调试工具，上线后忘了关，会在每个响应头里塞时间戳，悄悄拖慢 5–8ms。这些细节不会报错，但会持续侵蚀 P99 延迟。
