Flask的app.run()严禁用于生产环境，因其单线程阻塞模型导致请求卡死即全服务停摆，且无进程看护、无超时控制、无结构化日志；必须改用Gunicorn等WSGI服务器，并配合Nginx处理静态文件、连接缓冲与TLS终止。
Flask自带的app.run()绝对不能用于生产环境——它不是“不够好”，而是根本没设计成干这个活的。
为什么app.run()在生产中会挂得毫无征兆
你看到的WARNING: This is a development server. Do not use it in a production deployment.不是客气话，是明确的技术禁令。它的单线程阻塞模型意味着：
- 一个请求卡住（比如数据库慢查询、外部 API 超时），整个进程就停摆，后续所有请求排队等死
- 没有进程看护：worker崩溃后不会自动重启，
502 Bad Gateway直接甩给 Nginx 或用户 - 无超时控制：
timeout参数根本不存在，恶意长连接或慢速攻击能轻易耗尽资源 - 日志极简：错误只打到终端，没访问日志、没结构化错误追踪，出问题只能靠猜
gunicorn启动时最常见的ImportError和路径问题
执行gunicorn myapp:app报ImportError: cannot import name 'app'，90% 是模块导入路径没理清：
-
myapp必须是一个可导入的 Python 包（即目录下有__init__.py），不能只是个.py文件 -
app必须是模块顶层的全局变量名，不能藏在函数里、类方法里，也不能被if __name__ == '__main__':包裹 - 当前工作目录要确保在
myapp所在父目录下，否则 Python 找不到包 - 虚拟环境要激活，且
gunicorn和你的应用依赖都在同一环境中
--workers设多少才合理？别硬套公式
workers = multiprocessing.cpu_count() * 2 + 1是通用建议，但实际得看负载类型：
立即学习“Python免费学习笔记（深入）”；
- CPU 密集型（如图像处理）：worker 数接近 CPU 核数，再多反而因 GIL 切换拖慢整体
- IO 密集型（如调第三方 HTTP、数据库）：可以适当提高，比如
--workers 8配--threads 4，但要注意数据库连接池是否撑得住 - 内存受限时：每个 worker 占用独立内存，worker 太多可能 OOM；用
ps aux | grep gunicorn观察 RSS 值 - 开发机测试别设太高：2 核机器上跑
--workers 10，反而因上下文切换降低吞吐
不加 Nginx 直连 gunicorn 的风险被严重低估
很多人以为“gunicorn 跑起来就能上线了”，但跳过 Nginx 会立刻暴露三个硬伤：
- 无静态文件服务：
gunicorn不处理/static/xxx.js，全扔给 Flask，白白消耗 worker - 无连接缓冲：大请求体（如文件上传）可能触发
ConnectionResetError，Nginx 的client_max_body_size和缓冲能兜底 - 无 TLS 终止：HTTPS 解密必须由前端服务器做，
gunicorn自带 SSL 支持既难配又不推荐（性能差、证书管理麻烦）
真正上线时，gunicorn 永远该监听 127.0.0.1:8000 这类内网地址，把面向公网的活全交给 Nginx。
