FastAPI 用 Uvicorn 部署：进程管理、代理头与优雅停止
FastAPI 使用 ASGI 运行方式，但应用能导入并不等于已经具备稳定的生产部署。监听地址、进程数量、启动任务和外部代理要一起规划。本文以 Linux、Python 3.12 及项目已验证的受维护 FastAPI、Uvicorn 版本为例，假设应用对象位于 main 模块。
先把开发运行与生产运行分开
开发时的自动重载会监视代码变化并重启，不适合作为正式发布机制。生产应运行固定发布版本，并由系统服务或容器平台监督。依赖在发布前安装并测试，不要每次服务启动都临时下载不同版本。
使用 main:app 前，确认实际模块可被导入，应用配置来源正确。初始化连接、加载模型等行为需要评估失败方式：如果依赖尚未可用，程序应产生清楚日志，而不是看似启动成功后一直返回错误。
选择有限工作进程和明确监听
在独立虚拟环境中，下面是同机反向代理场景的启动示例：
.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8000 --workers 2 --proxy-headers --forwarded-allow-ips 127.0.0.1 --timeout-graceful-shutdown 30
参数中的进程数和停止等待时间是测试起点，需要根据业务调整。--reload 与多工作进程不是应同时用于生产的组合。具体参数及环境变量规则可查Uvicorn 设置文档。
若代理在另一容器或主机，监听地址和可信来源必须按拓扑替换。不能把命令中的回环地址原样搬到跨容器场景，也不能为了连接成功就将所有来源设为可信。
多个进程意味着多份应用状态
工作进程可以利用多个 CPU 执行单元，但每个进程通常有自己的内存与连接池。加载大型模型、持有缓存或建立大量数据库连接时，增加进程会同步增加资源需求，不能只按核心数机械设置。
生命周期事件会在各个工作进程中发生。数据库迁移、定时任务或只应执行一次的消息处理，不应无保护地放入每个进程启动逻辑。需要共享状态时使用适合的外部存储或协调机制，而不是指望某个进程里的全局变量自动共享。FastAPI 工作进程说明
异步函数也不保证任何代码都不会阻塞。同步耗时计算或不合适的阻塞调用仍可能影响响应，应按应用实际行为分析，而不是单纯追加 workers。
通过真实代理入口验证协议与路由
让正式入口处理 HTTPS 时，应用应识别正确的外部协议和路径。可信代理设置只接受实际代理提供的信息；如果代理有多层，记录每层来源与头部处理方式，避免错误信任访客自填地址。
分别测试正常接口、认证失败、参数错误和不存在路径，确认状态码与响应内容符合接口约定。若应用挂载在路径前缀下，还要核对文档页面和生成链接使用的根路径，不能只测试一个固定接口。
健康检查可以区分进程存在和关键依赖就绪，但不要让每次检查都进行昂贵操作或写入真实业务。记录检查失败时平台如何处理，避免把暂时依赖故障变成持续重启。
停止与升级需要留出处理窗口
交给服务管理器时使用完整程序路径和固定工作目录，不依赖手工激活的终端环境。确认退出信号能够让应用停止接收新请求，并在合理窗口内处理已有请求；长任务应有可恢复的执行方式，不能只靠延长等待保证完成。
发布失败时恢复旧代码、环境和启动参数，先确认数据库与外部状态仍兼容。验收包括日志、正常请求、受控重启和依赖短暂不可用的处理。最终保留进程数量、连接池预算与可信代理范围，作为下一次扩容或迁移的依据。