Flask开发服务器严禁用于生产环境，因其单线程阻塞模型导致请求排队、无超时控制、易受慢速攻击且崩溃即全挂；必须改用Gunicorn等WSGI服务器并配合Nginx。
Flask开发服务器（flask run 或 app.run()）根本不是为生产设计的——它连“勉强可用”都算不上，而是明确被禁用的运行模式。
单线程阻塞模型让并发请求直接排队等死
它默认只用一个线程处理所有请求。哪怕加了 --with-threads，底层仍是 Werkzeug 的简易同步服务器，没有真正的调度能力。
- 一个请求卡住（比如
time.sleep(5)、未设 timeout 的requests.get()、慢 SQL），后续所有请求必须原地等待 - 实测 50 并发就开始丢包；100 并发时平均响应时间常超 8 秒
- 这不是配置能调好的问题，是模型本身不支持并发
ImportError: cannot import name 'app' 不是代码错，是导入上下文崩了
执行 gunicorn myapp:app 报这个错，90% 是环境没对齐：
-
myapp必须是含__init__.py的 Python 包，不能只是myapp.py文件 -
app必须是模块顶层的全局变量，不能藏在函数里、类方法里，也不能被if __name__ == '__main__':包裹 - 当前工作目录得在
myapp的父目录下，否则python -c "import myapp"都失败 - 虚拟环境必须激活，且
gunicorn和你的应用依赖安装在同一环境里
--workers 数不是越多越好，CPU、IO、内存三者互相牵制
盲目套用 workers = multiprocessing.cpu_count() * 2 + 1 容易翻车：
- CPU 密集型任务（如图像处理）：worker 数接近物理核数即可，再多反而因 GIL 切换拖慢整体
- IO 密集型任务（如 HTTP 调用、数据库查询）：可适当提高，但得配好连接池（如 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 跑起来就能上线，其实立刻暴露三个硬伤：
- 静态文件全扔给 Flask 处理：
/static/js/app.js这种请求也走 Python，白白消耗 worker - 大请求体（如上传 10MB 文件）可能触发
ConnectionResetError——Gunicorn 没缓冲，Nginx 的client_max_body_size和缓冲机制才能兜底 - 无 TLS 终止：HTTPS 解密必须由前端完成，Gunicorn 只负责 HTTP，裸跑等于放弃加密层
真正容易被忽略的是：Gunicorn 不是 flask run 的“升级版命令”，而是一个需要独立配置、监控、限流、与 Nginx 协同的生产级服务组件。漏掉任一环，上线即翻车。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
