Flask 用 Gunicorn 部署：工作进程、反向代理与生产配置
Flask 应用在开发环境运行成功后，还需要生产应用服务器、进程管理和网络入口。本文适用于 Linux、Python 3.12 与项目已验证的受维护 Flask、Gunicorn 版本，讨论普通 WSGI 应用；异步接口或实时通信还需按实际协议选择工作方式。
先确认应用导入入口
常见的 app:app 表示从 app 模块导入名为 app 的应用对象，并不是网址或文件系统绝对路径。应用工厂则使用对应的工厂调用写法。先在独立虚拟环境和受控配置下确认导入成功，再交给进程管理器。
导入应用时若自动执行数据库迁移、发送通知或启动定时任务，多工作进程可能重复触发这些动作。上线前应把一次性初始化与每个进程的启动职责分开。Flask 的 Gunicorn 部署示例可参考官方部署文档。
先以回环地址启动一个可控实例
在项目目录中，使用已经安装依赖的虚拟环境运行。示例假设入口对象为 app，端口尚未被其他服务使用：
.venv/bin/gunicorn --workers 2 --bind 127.0.0.1:8000 --access-logfile - --error-logfile - app:app
两个工作进程只是便于开始验证的示例，不是按服务器配置推荐的容量。前台运行有助于首次观察启动错误；确认后再由专用账号的服务管理器托管，不要以 root 长期运行，也不要同时开多个实例争抢端口。
运行账号需要合适的运行目录与必要写权限，包括所用版本可能使用的控制或临时文件位置。权限不足时修正具体路径，不能将整个应用树设置为任意人可写。
按请求特点选择工作方式
默认同步工作方式与线程、其他工作类型的行为不同，适合范围也不同。普通页面、长时间外部请求和大规模连接不能用同一套简单进程公式概括。先测单次内存和典型请求，再逐步观察并发下的响应与数据库连接数。
出现工作进程超时，应检查应用是否被慢查询、锁或外部接口阻塞，不能只增大超时。回收进程和限制请求数量可以辅助维护，但不替代修复持续增长的内存问题。各参数含义与版本支持见Gunicorn 配置参考。
用代理处理正式入口
同机 Nginx 可以代理到回环端口，统一管理域名、HTTPS 和静态资源。外部请求协议、客户端地址和 Host 信息需要按可信代理链处理；应用不能无条件相信任何访客提交的转发头。
先验证通过代理的路由、登录跳转和资源地址。如果本机正常、域名异常，区分路径变化、协议识别和代理配置，不要急着调整工作进程数量。开发调试模式和自动代码重载不应作为生产运行方式。
静态资源与用户上传的存储位置也需要明确。应用升级目录被替换时，持久化附件不能跟着丢失；备份应包含数据库与必要文件，而不是只有虚拟环境和代码。
服务托管与回退一起验收
把完整 Gunicorn 路径、工作目录、账号与配置来源写进既定服务管理方式，并保证程序保持前台由管理器监督。查看服务状态与错误日志后，再验证真实页面和安全测试业务，不能只看端口已经监听。
在维护安排下检查停止和重新启动，确认正在处理的请求有合理退出时间，客户端不会反复重复写入。发布前保留旧代码、依赖环境和匹配配置；回退前先核对数据库兼容性。这样问题出现时可以恢复已知版本，而不是在运行目录中临时更换一串依赖。