FastAPI 必须搭配 ASGI 服务器（如 uvicorn[standard]）运行，否则无法并发或启动；开发用 --reload，生产需禁用并手动指定 workers；async 路由中禁用同步阻塞调用；Linux/macOS 应启用 uvloop 提升吞吐量。
FastAPI 本身不直接运行，它依赖 ASGI 服务器。没选对或配错 uvicorn 参数，服务就卡在开发模式、无法并发、甚至启动失败。
必须装 uvicorn[standard]，不是只装 uvicorn
只执行 pip install uvicorn 会漏掉关键依赖：比如 httptools（高性能 HTTP 解析器）和 watchfiles（--reload 的底层监听器）。结果是：--reload 不生效、高并发下解析慢、日志里频繁报 RuntimeWarning: coroutine 'Lifespan.on_startup' was never awaited。
正确命令是：
pip install "uvicorn[standard]"
方括号不是可选语法糖，是 pip 的 extras 机制，[standard] 显式声明需要完整生产级依赖。
开发用 --reload，生产必须关掉并指定 workers
--reload 依赖文件系统 inotify，只适合本地开发。放到 Docker 或 systemd 里会失效，还可能因热重载触发多次 on_startup 导致数据库连接重复初始化。
立即学习“Python免费学习笔记（深入）”；
- 开发：用
uvicorn main:app --reload --host 0.0.0.0 --port 8000 - 生产：禁用 reload，显式指定 worker 数 —— 建议设为 CPU 核心数 × 2，例如 4 核机器用
--workers 8 - 别信“自动检测 CPU”的说法：
uvicorn默认只起 1 个 worker，--workers必须手动写
async/await 路由函数里混同步阻塞调用，性能直接归零
写了 async def 不等于异步生效。常见踩坑：
- 调用
requests.get()—— 这是同步阻塞，整个 event loop 被卡住 - 用
time.sleep(1)—— 同样阻塞，应换await asyncio.sleep(1) - ORM 查询没走异步驱动，比如用
sqlalchemy.orm.sessionmaker而非sqlalchemy.ext.asyncio.AsyncSession
验证方法：压测时看 CPU 使用率是否长期低于 30%，同时 uvicorn 日志出现大量 WARNING: Slow request —— 这就是同步操作拖垮了异步管道。
别忽略 --loop uvloop（Linux/macOS 下强推）
uvloop 是 asyncio 的 C 扩展实现，实测比默认 asyncio 循环提升 2–3 倍吞吐量。但 Windows 不支持，所以得加平台判断：
启动命令里加上：
uvicorn main:app --workers 4 --loop uvloop
如果部署在 Windows 上，这条参数要删掉，否则启动报错 ModuleNotFoundError: No module named 'uvloop'。
真正容易被忽略的点是：哪怕你代码写得再规范，只要 uvicorn 没跑在 uvloop 上，就浪费了 FastAPI 一半的性能潜力 —— 尤其在 I/O 密集场景，比如 API 大量调用外部 HTTP 接口或数据库。
