Flask开发服务器不可用于生产，因其单线程阻塞、无超时、无自动重启；gunicorn报ImportError多因包结构或路径错误；worker数需按负载类型调整；跳过Nginx直连gunicorn会导致静态文件处理低效、大请求体失败、HTTPS配置困难及日志缺失。
Flask默认开发服务器根本没设计成干生产活的，不是“差点意思”，而是压根拒绝承担这个职责。
单线程阻塞模型让整个服务一卡全卡
Werkzeug内置服务器是同步、单线程的。一个请求卡住（比如 requests.get() 没设 timeout、数据库慢查询、time.sleep(5)），后续所有请求就排队等它结束。
- 现象：
curl http://your-server/fast在/slow正在执行时直接卡住 5 秒以上 - 没有超时控制：连接不会被主动断开，恶意慢速攻击（如 Slowloris）几条连接就能拖垮服务
- 崩溃即全挂：进程退出后不会自动重启，用户看到的是 502 或直接连接失败
gunicorn myapp:app 报 ImportError 的真实原因
这不是代码写错了，是 Python 导入上下文没对齐。报 ImportError: cannot import name 'app' 时，90% 是路径或结构问题：
-
myapp必须是可导入的包（含__init__.py），不能只是myapp.py文件 -
app必须是模块顶层的全局变量，不能藏在函数里、类方法里，也不能被if __name__ == '__main__':包裹 - 当前工作目录得在
myapp的父目录下，否则python -c "import myapp"都失败 - 虚拟环境必须激活，且
gunicorn和你的应用依赖安装在同一环境里
--workers 数值不是套公式就能用的
workers = multiprocessing.cpu_count() * 2 + 1 是通用建议，但实际负载类型决定上限：
立即学习“Python免费学习笔记（深入）”；
- CPU 密集型（如图像处理）：worker 数接近物理核数，再多反而因 GIL 切换拖慢整体
- IO 密集型（如调 HTTP、查数据库）：可以提高 worker 数，但必须配好数据库连接池（如 SQLAlchemy 的
pool_size），否则触发OperationalError: too many connections - 内存受限时：每个 worker 独占一份内存镜像，用
ps aux | grep gunicorn看RSS值，OOM 前就得降数 - 开发机别设太高：2 核机器跑
--workers 10，上下文切换开销反而压低吞吐
跳过 Nginx 直连 gunicorn 就等于裸奔
只跑 gunicorn -b 0.0.0.0:8000 myapp:app 上线，立刻暴露三个硬伤：
- 静态文件全扔给 Flask 处理：
/static/js/app.js这种请求也走 Python，白白消耗 worker - 大请求体（如上传 10MB 文件）可能触发
ConnectionResetError——Gunicorn 没缓冲，Nginx 的client_max_body_size和proxy_buffer才能兜底 - HTTPS 解密必须由前端服务器做，gunicorn 自带 SSL 支持既难配又不推荐（性能差、证书管理麻烦）
真正容易被忽略的点是：错误日志和访问日志完全缺失。开发服务器只往终端打错，出问题只能靠猜；而生产环境需要结构化日志、按时间轮转、分离 access/error，这些都得靠 Gunicorn 配置项（如 --access-logfile、--error-logfile）和 Nginx 共同完成。
