生产环境禁用--reload，必须用systemd或Gunicorn管理进程、Nginx反向代理，并配置--workers、--limit-concurrency等参数保障高并发与稳定性。
直接上生产环境别用 uvicorn main:app --reload，它只适合本地开发；云服务器必须配合进程管理或反向代理，否则一断连就挂、并发上不去、日志没归档、端口暴露不安全。
云服务器部署必须禁用 --reload
这个参数依赖文件系统 inotify 监控，在多数云服务器（尤其是容器、NAS挂载盘、某些 systemd 环境）下会失效或触发频繁重启。更严重的是：--reload 和 --workers 互斥，意味着你根本开不了多进程——单进程扛不住真实请求量。
- 现象：改了代码没反应、
uvicorn进程莫名退出、inotify watch limit exceeded错误出现在journalctl -u your-service里 - 正确做法：开发用
--reload，上云前删掉；靠systemd或gunicorn做进程生命周期管理 - 替代方案：若真需要热更新（如灰度发布），应走滚动重启 + 负载均衡器健康检查，而不是依赖文件监听
用 systemd 管理 Uvicorn 进程（无 Nginx 场景）
适合内网服务、调试接口、或轻量级后台 API，不对外暴露 HTTP 端口，但要保证崩溃自动拉起、日志可查、开机自启。
- 写
/etc/systemd/system/uvicorn.service，关键项必须包含：Restart=always、RestartSec=5、StandardOutput=append:/var/log/uvicorn.log、User=www-data（非 root） - 启动命令别写成
ExecStart=uvicorn main:app，要显式指定--host 0.0.0.0 --port 8000 --workers 4 --log-level info - 务必执行
sudo systemctl daemon-reload && sudo systemctl enable uvicorn && sudo systemctl start uvicorn，缺一步服务就不生效 - 验证：
sudo systemctl status uvicorn看 Active 状态，sudo journalctl -u uvicorn -n 20查最近日志
必须加 Nginx 反向代理（暴露公网时）
Uvicorn 不处理 TLS、静态文件、请求限流、IP 黑白名单、HTTP 头过滤等——这些全得由 Nginx 拦在前面。裸跑 Uvicorn 到公网等于把 Python 进程直接挂在防火墙外。
Uvicorn 0.52.1
下载
Uvicorn 0.52.1 是 Python ASGI Web 服务器，提供异步应用服务及 WebSocket 支持，常用于 FastAPI、Starlette 等应用的开发和部署。本下载为官方 PyPI 通用 wheel 包，可使用 pip 安装，并由包管理器处理所需依赖。
- Nginx 配置里
proxy_pass http://127.0.0.1:8000后，必须加：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade（WebSocket 必需）、proxy_set_header Connection "upgrade" - Uvicorn 启动时加
--forwarded-allow-ips="127.0.0.1"，否则request.client.host会变成127.0.0.1，丢失真实用户 IP - 别漏掉超时设置：
proxy_read_timeout 300（长任务）、proxy_send_timeout 300，否则 Nginx 默认 60 秒就断连接 - 静态资源（如
/static/）直接让 Nginx serve，别转发给 Uvicorn，省 CPU、快十倍
gunicorn + uvicorn.workers.UvicornWorker 是最稳的生产组合
很多人以为 Gunicorn 是 WSGI 专属，其实它通过 uvicorn.workers.UvicornWorker 完美支持 ASGI，还能解决 Uvicorn 单点故障、冷启动慢、信号处理不完善等问题。
- 安装必须用
pip install "gunicorn[standard]" "uvicorn[standard]"，否则uvloop和httptools缺失，性能打七折 - 启动命令示例：
gunicorn main:app -c gunicorn.conf.py，配置里worker_class = "uvicorn.workers.UvicornWorker"是核心 -
workers数建议设为2 * multiprocessing.cpu_count() + 1，但最大别超 8——Uvicorn 本身是异步的，太多 worker 反而抢 GIL、增加上下文切换开销 - 务必配
timeout = 120和graceful_timeout = 120，避免大文件上传或数据库慢查询被粗暴 kill
真正容易被忽略的点是：Uvicorn 的 --limit-concurrency 和 --backlog 参数在高并发突增时比 worker 数还关键；很多“压测卡死”问题其实不是 CPU 扛不住，而是连接队列溢出或并发数硬限导致请求直接被丢弃，连日志都不留。
