不能只用Uvicorn跑生产服务，因其单进程模型缺乏进程管理、平滑重启、超时熔断、连接限制等能力，易因崩溃或内存泄漏导致服务不可用。
为什么不能只用 Uvicorn 跑生产服务
Uvicorn 本身是高性能 ASGI 服务器，但默认只启一个 worker 进程，扛不住真实流量。哪怕开了 --workers，它对进程管理、信号处理、平滑重启的支持远不如成熟 WSGI/ASGI 网关。线上挂一次，可能就因为某个 worker 崩溃后没被拉起。
- Uvicorn 单进程模型在内存泄漏或长阻塞任务下极易夯死
- 没有内置的请求超时熔断、连接数限制、慢日志追踪能力
- 不支持优雅 reload（比如代码热更时，旧请求还在跑，新 worker 已上线）
- 健康检查端点、metrics 暴露、日志格式化都得自己 patch
Gunicorn + Uvicorn 组合里，谁管什么
Gunicorn 是主调度层，负责 fork 多个 Uvicorn worker、监听 socket、分发连接、做 graceful shutdown；Uvicorn 只专注单个 worker 内的异步事件循环和 HTTP 解析。两者不是并列关系，而是“Gunicorn 启 Uvicorn 实例”。
- Gunicorn 控制
workers数量、timeout、preload、max_requests - Uvicorn 只接收 Gunicorn 传入的
bind和workers（注意：这个workers在组合模式下必须设为 1） - 真正生效的并发能力 = Gunicorn 的 worker 数 × Uvicorn 单 worker 的 async 并发上限（通常 1000+）
- 别在 Uvicorn 命令行里写
--workers 4—— 这会跟 Gunicorn 冲突，导致启动失败或资源争抢
配置文件里最容易错的三个参数
很多人抄示例时直接粘贴 gunicorn.conf.py，但没理解每个字段的实际作用域。以下三个参数一旦设错，轻则压测打不满 CPU，重则服务启动就报 Address already in use 或静默退出。
-
bind = "0.0.0.0:8000"：必须显式指定，且不能跟 Uvicorn 自己的 bind 冲突；推荐用unix:/tmp/gunicorn.sock配合 nginx 反向代理 -
worker_class = "uvicorn.workers.UvicornWorker"：这是关键胶水，漏写就退化成同步 worker -
workers = 4：建议设为2 × CPU 核数，但别盲目堆高；超过 8 个后 Gunicorn 进程调度开销明显上升，反而降低吞吐
示例最小可用配置：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
bind = "unix:/tmp/gunicorn.sock" workers = 4 worker_class = "uvicorn.workers.UvicornWorker" timeout = 120 keepalive = 5 preload = True accesslog = "-" errorlog = "-"
部署后必查的五个信号与日志线索
服务跑起来不等于能稳住。很多线上抖动问题，根源在系统层或配置层没对齐，靠看应用日志根本发现不了。
- 查
ps aux | grep gunicorn：确认是 Gunicorn master 进程 + 几个 Uvicorn worker 子进程，而不是一堆孤立的 uvicorn 进程 - 查
netstat -tuln | grep :8000：只有 Gunicorn master 在 listen，worker 不该单独占端口 - 看 accesslog 里每行开头是否带
[01/Jan/2024:12:00:00 +0000]时间戳 —— 没有说明 Gunicorn 日志没生效，可能是accesslog路径权限不对或设成了None - 压测时观察
gunicorn.error.log是否频繁出现Worker failed to boot或Worker exiting after N requests，对应调max_requests和preload - 用
curl -v http://localhost/healthz测试健康接口是否返回 200 —— 如果超时，大概率是 Gunicorn 的timeout设太小，或者 Uvicorn worker 卡在某个 await 上没响应
最常被忽略的是 preload=True：它让 Gunicorn 在 fork 前先加载一次应用代码，避免每个 worker 单独 import 导致的内存重复占用和初始化竞争。不加这个，16 个 worker 可能吃掉 3GB 内存，加了之后稳定在 1.2GB 左右。
