Flask开发服务器不能用于生产是硬性事实，因其单进程、无连接池、不支持HTTPS终止、无优雅重启、挂即中断，且并发时请求阻塞、响应时间指数恶化。
Flask开发服务器不能用于生产，这是硬性事实，不是建议。它单进程、无连接池、不处理静态文件、不支持HTTPS终止、挂了就彻底中断——这些在 flask run 启动时的 WARNING 日志里已经写得清清楚楚。
为什么必须用 Gunicorn 而不是直接跑 app.run()
因为 app.run() 是 Werkzeug 开发服务器，本质是单线程阻塞式 HTTP 服务。哪怕加了 threaded=True，也只是简单多线程，没有进程管理、无超时控制、无健康检查、无法优雅重启。真实用户并发一上来，/slow 接口卡住 5 秒，所有后续请求全排队等，响应时间指数级恶化。
- 单 Worker 模式下，一个请求出错或死循环，整个服务就不可用
- 不支持 graceful shutdown，kill -15 会直接中断正在处理的请求
- 日志无结构、无请求 ID、无法对接 ELK 或 Prometheus
- 内存泄漏风险高，长期运行后 RSS 持续上涨
gunicorn 启动命令里几个关键参数怎么选
启动命令形如：gunicorn --bind 127.0.0.1:8000 -w 4 -t 120 --max-requests 1000 app:create_app('production')。每个参数都直接影响稳定性：
-
--bind必须绑定127.0.0.1（非0.0.0.0），否则 Nginx 反向代理失效且暴露内部端口 -
-w（worker 数）建议设为 CPU 核心数 × 2 + 1，但不超过 8；超过后上下文切换开销反超收益 -
-t（timeout）默认 30 秒太短，API 类项目建议调到 90–120 秒，避免数据库慢查询被误杀 -
--max-requests强制 Worker 重启，防止内存累积泄漏；1000 是较安全的起点，可按压测结果调整 - 工厂函数模式必须写成
app:create_app('production')，写成app:app会报AttributeError: module 'app' has no attribute 'app'
Nginx 配置里最容易漏掉的三处关键项
Nginx 不只是反向代理，更是生产环境的第一道防线。以下配置缺一不可：
-
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for：否则 Flask 中request.remote_addr永远是127.0.0.1，IP 限流、地域判断全失效 -
proxy_set_header X-Forwarded-Proto $scheme：没这行，Flask 生成的重定向 URL 会变成http://，即使开了 HTTPS 也会跳转失败 -
client_max_body_size 10M：上传文件默认只允许 1MB，大附件直接 413 Request Entity Too Large - 额外提醒：静态文件别让 Gunicorn 处理，Nginx 应直接
location /static { alias /var/www/myapp/static/; }，减少 Python 进程负担
systemd 服务配置中必须检查的权限与路径
用 systemctl 管理 Gunicorn 是最稳妥的开机自启方式，但路径和权限错一点就启动失败：
-
User=建议设为非 root 用户（如www-data或自建flaskuser），避免 Gunicorn 进程拥有过高权限 -
WorkingDirectory=必须指向项目根目录，且该目录对User有读+执行权限（chmod 755） -
ExecStart=中的gunicorn路径要用绝对路径（/home/flaskuser/.local/bin/gunicorn），不能依赖$PATH -
Environment="PATH=..."必须显式声明，否则虚拟环境里的包可能找不到 - 日志路径（
StandardOutput）要提前touch并chown，否则 systemd 会静默失败
真正难的从来不是“怎么配”，而是“配完之后谁来保障它持续可用”——比如 Gunicorn Worker 内存涨到 500MB 是否自动重启？Nginx 连接数突增是否触发限流？这些不在配置文件里，而在监控和告警逻辑中。先让服务跑起来，再让它活下来，最后才谈得上跑得稳。
