Uvicorn生产环境禁用--reload可显著降低CPU和内存占用，因该参数会持续监听文件、反复fork子进程并重复加载模块；实测删除后常驻内存从1.2GB降至200MB左右。
Uvicorn启动时带--reload导致CPU和内存双高
这是FastAPI项目在Docker中部署后Uvicorn内存飙升最常见的原因。开发阶段用--reload方便热重载，但生产环境主进程会持续监听文件变化、启动子进程、反复fork+exec，不仅吃CPU，还会因残留进程和重复加载模块造成内存堆积。实测显示，删掉--reload后，常驻内存能从1.2GB直接回落到200MB左右。
检查你的docker-compose.yml或启动命令，确认没有类似这样的配置：
command: uvicorn main:app --host 0.0.0.0:8000 --port 8000 --reload
改成生产模式写法：
command: uvicorn main:app --host 0.0.0.0:8000 --workers 4 --loop uvloop --http httptools
-
--reload只应在本地开发使用，CI/CD流水线或Docker镜像构建阶段也必须禁用 - 若用
gunicorn做进程管理器（比如gunicorn -k uvicorn.workers.UvicornWorker），--reload更不能出现在任何层级 - 某些IDE插件或脚本会自动注入
--reload，建议在容器内执行ps aux | grep uvicorn确认实际运行参数
worker数量设置不合理引发内存泄漏式增长
Uvicorn默认只启1个worker，看似省内存，但高并发下单worker事件循环容易卡住，请求排队、连接堆积、超时重试，最终表现为内存缓慢上涨且不释放。反过来说，worker设太多（比如8核机器配16个worker）也会因上下文切换和共享资源争抢，导致每个worker额外多占80–120MB内存。
推荐配置原则：
Uvicorn 0.52.1 是 Python ASGI Web 服务器，提供异步应用服务及 WebSocket 支持，常用于 FastAPI、Starlette 等应用的开发和部署。本下载为官方 PyPI 通用 wheel 包，可使用 pip 安装，并由包管理器处理所需依赖。
- worker数 = CPU逻辑核心数 + 1（例如4核就设5个）
- 内存紧张时可降为CPU核心数，但别低于2（否则无法利用多核）
- 配合
--limit-concurrency 1000防止单worker堆积过多连接 - 若用Redis或数据库长连接，确保每个worker独享连接池，避免跨worker复用导致句柄泄漏
Pydantic模型或大型依赖被反复导入
FastAPI重度依赖Pydantic，而Pydantic v2的BaseModel在首次导入时会动态生成大量代码对象并缓存，如果项目结构把模型分散在多个模块、又在路由中频繁from xxx import *，会导致同一模型被多次解析，sys.modules里出现冗余副本，GC难以回收。
典型症状：Uvicorn进程RSS持续缓慢上涨，重启后回落，几小时后又回到高位。
- 统一在
models/目录集中定义所有Pydantic模型，全局只import一次 - 避免在
router文件里直接from pydantic import BaseModel，改用from models import UserSchema - 启用
pydantic.v1兼容层（如必须）会加重开销，v2已优化不少，优先升级 - 用
tracemalloc快速定位大对象来源：python -X tracemalloc=10 -m uvicorn main:app
，然后访问/docs后调用tracemalloc.take_snapshot()分析
Docker容器未限制内存上限，OOM Killer误杀或缓存失控
没设mem_limit的容器，Linux内核会把空闲内存全给Uvicorn做page cache，表面看RSS很高，其实是缓存；但一旦其他进程申请内存，Uvicorn又来不及释放，可能触发OOM Killer直接干掉worker进程，日志里只留Killed process。
务必在docker-compose.yml中显式约束：
deploy:
resources:
limits:
memory: 1.5G
- 设限值要比预估峰值高20%，比如压测发现稳定在1.1G，就设1.5G
- 配合
--max-requests 1000让worker定期重启，强制释放长期持有的引用 - 禁用
swap（mem_reservation不推荐），避免交换延迟放大响应时间
--reload，结果Dockerfile里CMD又写死了一次；或者worker数调对了，但Redis客户端没配max_connections，连接池随worker数翻倍膨胀——这些细节叠加起来，才让内存看起来“莫名其妙”地高。 
