必须删除所有app.run()，否则Gunicorn不生效；需显式配置workers数量与worker-class类型，合理匹配CPU核心数和业务类型，并验证日志中实际worker数及配置加载情况。
删掉所有 app.run()，否则 Gunicorn 根本不生效
这是最常被忽略的一步。Gunicorn 启动时会直接导入你的模块并调用 WSGI callable（比如 app），完全绕过 if __name__ == '__main__': app.run()。但如果你没删它，而是在本地测试时又手动运行 python app.py，就会误以为“启动成功”，实际跑的仍是 Werkzeug 单线程开发服务器——并发能力毫无提升，还带一堆警告：WARNING: This is a development server. Do not use it in a production environment.
务必检查整个项目：包括 app.py、main.py、run.py 等所有可能被直接执行的入口文件，把所有 app.run(...) 行注释或删除。
--workers 数值不是越多越好，得看 CPU 核心数和业务类型
盲目设 --workers 16 在 4 核机器上，大概率导致进程争抢 GIL、内存暴涨、响应变慢。CPython 的全局解释器锁让多进程对 CPU 密集型任务收益极低。
- CPU 密集型（如图像处理、数值计算）：用默认
--worker-class sync，--workers设为2 * CPU核心数 + 1（例如 4 核 →--workers 9） - I/O 密集型（如频繁查数据库、调外部 API）：可尝试
--worker-class gevent，单 worker 并发处理数百请求，但必须在应用最开头加from gevent import monkey; monkey.patch_all() - 不确定类型或刚上线：先用
--workers 4 --worker-class sync跑通，再压测调整
启动时加 --log-level info，日志里会明确打出实际加载的 worker 数量，避免“以为起了 8 个，其实只起了 1 个”。
立即学习“Python免费学习笔记（深入）”；
Flask 配置不会自动生效，必须显式加载
Gunicorn 不解析 .env 或 config.py，它只管启动 WSGI 应用。你代码里写的 DEBUG=True 或 SECRET_KEY，如果没在应用初始化阶段显式载入，线上就还是默认值。
推荐做法是在入口模块（如 app.py）中显式加载：
app.config.from_object('config.ProdConfig')或用绝对路径加载配置文件：
app.config.from_pyfile(os.path.join(os.path.dirname(__file__), 'config.py'))
别依赖 FLASK_ENV=production —— 这个环境变量从 Flask 2.3 起已废弃，--env FLASK_ENV=production 对 Gunicorn 无效，也不影响 Flask 行为。
Nginx 反向代理必须透传关键头，否则 Flask 拿不到真实 IP 和协议
只写 proxy_pass http://127.0.0.1:8000; 是不够的。Flask 生成重定向 URL、记录日志、做权限判断时，都依赖原始请求头。缺了它们，会出现 Redirecting to https://localhost/login 或 request.remote_addr 始终是 127.0.0.1。
Nginx 配置里必须包含：
proxy_set_header Host $host;<br>proxy_set_header X-Real-IP $remote_addr;<br>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br>proxy_set_header X-Forwarded-Proto $scheme;
其中 $scheme 是关键：它把 https 或 http 传给 Flask，否则 url_for(..., _external=True) 生成的链接永远是 http 开头。
真正卡住人的地方，往往不是怎么写命令，而是 Gunicorn 启动后你以为它在跑多进程，其实还在用 app.run()；或者你以为配置已生效，结果 Flask 根本没读到 config.py。每一步都要验证：看日志、查进程树、curl 测 header。
