gunicorn并发未提升反变慢，主因是进程数设置不当或未关闭Flask调试模式；必须删除app.run()、显式加载配置、合理选worker数与类型，并检查初始化异常。
为什么 gunicorn 启动后并发没提升，反而更慢了？
根本原因常是进程数设得不合理，或没关掉 Flask 自带的调试模式。Flask 的 app.run() 是单线程开发服务器，gunicorn 一上来就绕过它——但如果你在代码里还写了 if __name__ == '__main__': app.run(...)，又没加 --reload 或环境判断，可能实际跑的还是 Flask 原生 server。
- 必须删掉或注释掉所有
app.run()调用，gunicorn不会执行它 - 默认启动命令
gunicorn app:app中的第二个app是 WSGI callable 名，不是文件名；如果入口是main.py且变量叫application，就得写成gunicorn main:application -
--workers别盲目设高：CPython 的 GIL 让 CPU 密集型任务多进程收益有限；I/O 密集型（如数据库查询、HTTP 调用）才真正受益，建议从2 × CPU 核心数开始试 - 启动时加
--log-level info，能看到实际加载了多少 worker 和线程，避免“以为起了 4 个，其实只起了 1 个”
--worker-class 选 sync 还是 gevent？
默认 sync 是阻塞式，每个 worker 处理一个请求，适合简单逻辑、短响应；gevent 是协程模型，单 worker 可并发处理数百请求，但要求所有依赖库都兼容 gevent（比如 psycopg2 要换成 psycopg2cffi 或加 monkey patch）。
- 用
gevent前必须在应用最开头插入：from gevent import monkey; monkey.patch_all() - 数据库连接池要重配：Flask-SQLAlchemy 的
pool_size和max_overflow得配合 gevent 并发数调大，否则连接池会成为瓶颈 - 如果用了
requests，它默认不兼容 gevent，要么换gevent-requests，要么确保已打 patch（monkey.patch_socket()） - 本地开发可先用
sync+--workers 2验证流程，再切gevent；线上压测时，gevent在 I/O 密集场景下 QPS 通常高 3–5 倍，但错误堆栈更难读
如何让 gunicorn 正确读取 Flask 的配置（比如 DEBUG=False）？
gunicorn 本身不解析 Flask 配置，它只管启动 WSGI 应用；所有 Flask 配置必须在 Python 代码里显式加载，不能依赖 .env 或 config.py 被自动识别。
- 推荐方式：在
app.py或入口模块中，用app.config.from_object('config.ProdConfig')显式加载类配置 - 避免用
app.config.from_pyfile('config.py')，因为路径容易因工作目录变化而失败；改用绝对路径：os.path.join(os.path.dirname(__file__), 'config.py') -
gunicorn的--env参数（如--env FLASK_ENV=production）对新版 Flask 无效，FLASK_ENV已废弃，靠它切换 debug 模式是徒劳的 - 关键配置项如
SECRET_KEY、SQLALCHEMY_DATABASE_URI必须在app实例创建后、注册蓝图前完成设置，否则扩展初始化会出错
部署时 gunicorn 进程意外退出，日志里只显示 Worker failed to boot
这通常是 WSGI callable 初始化阶段抛了异常，但 gunicorn 默认把 traceback 吞掉，只留一句提示。根本问题不在 gunicorn 本身，而在你的 app 创建过程里有未捕获的错误。
立即学习“Python免费学习笔记（深入）”；
- 先手动运行
python -c "from app import app; print(app)"，看是否能成功导入并实例化，这是最快速定位初始化失败的方法 - 常见坑：数据库 URL 格式错（漏了
postgresql://前缀）、Redis 连接超时没设socket_connect_timeout、环境变量缺失导致os.environ['SECRET_KEY']报KeyError - 加
--preload参数会让gunicorn在 fork worker 前先加载一次应用，能把部分延迟报错提前暴露出来 - 别忽略
--capture-output：它能让 worker 的 stdout/stderr 重定向到 gunicorn 日志，很多 “静默失败” 都靠它捞出真实错误行
多进程不是万能解药，worker 数、class、配置加载顺序、依赖兼容性，四者只要一个没对齐，就会卡在启动那一步。线上跑着的进程，往往是在某次配置变更后悄悄退化成单 worker 的——查 ps aux | grep gunicorn 比看文档更快。
