Flask生产部署必须用Nginx+Gunicorn组合：Gunicorn作为WSGI服务器运行应用并处理并发，Nginx负责反向代理、静态文件服务及安全防护；直接运行app.run()因单线程、无超时等缺陷绝不适用于生产环境。
Flask 自带的 app.run() 绝对不能直接上生产——它单线程、无超时、不守进程、不抗并发，一压就 502 或 504。真正能跑起来的组合是：Gunicorn 负责运行 Flask 应用（WSGI 层），Nginx 负责对外暴露、反向代理、静态文件和连接管理。
为什么 Gunicorn 启动后 curl 不通？常见端口与绑定问题
最常踩的坑是 Gunicorn 绑定地址写错，导致服务监听在错误位置，Nginx 根本连不上。
-
-b 127.0.0.1:8000是正确写法：只允许本地回环访问，Nginx 才能安全转发 -
-b 0.0.0.0:8000是危险操作：把 Flask 直接暴露到公网，绕过 Nginx 的防护和限流 -
-b :8000等价于0.0.0.0:8000，同样不推荐 - 确认端口没被占用：
sudo lsof -i :8000或ss -tuln | grep 8000 - 如果用
gunicorn app:app启动失败，先检查app.py是否定义了名为app的 Flask 实例（不是application或其他名）
Nginx 反向代理配置里最关键的三行
Nginx 不是“配对就行”，少一行或写错路径，就会返回 502 Bad Gateway。
-
proxy_pass http://127.0.0.1:8000;必须带末尾/或不带，且要和 Gunicorn 绑定端口严格一致 -
proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;这两行必须存在，否则 Flask 拿不到真实 IP 和域名，url_for(..., _external=True)会生成错误链接 - 不要漏掉
location /块外的client_max_body_size 10M;，否则上传大文件直接 413 Request Entity Too Large
Gunicorn worker 数量怎么设？别盲目照搬 -w4
worker 数不是越多越好，设错反而拖慢响应、耗尽内存。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
立即学习“Python免费学习笔记（深入）”；
- 默认
-w 1—— 单 worker 在 I/O 密集型场景（如调外部 API、数据库慢查询）下极易阻塞 - 通用公式：
2 × CPU 核数 + 1，例如 2 核机器用-w 5；但内存紧张时（如小 VPS）建议从-w 2或-w 3起步 - 如果用了
gevent，改用--worker-class gevent --workers 10 --worker-connections 1000，此时更看重连接数而非进程数 - 务必加
--timeout 30，防止某个请求卡死拖垮整个 worker - 启动时加
--access-logfile - --error-logfile -把日志打到 stdout，方便 Docker 或 systemd 收集
静态文件交给谁？别让 Gunicorn 处理
Flask 的 send_from_directory 或 url_for('static', ...) 在生产环境必须由 Nginx 直接服务，否则每个静态请求都要进 Python 进程，白白浪费资源。
- 在 Nginx 配置里显式声明：
location /static { alias /path/to/your/project/static/; }（注意alias末尾斜杠和路径一致性） - 确保目录权限可读：
chmod -R 755 /path/to/static，且 Nginx 用户（通常是www-data或nginx）有执行权限进入父目录 - Flask 中禁用静态路由：
app = Flask(__name__, static_folder=None)，彻底交由 Nginx 接管 - 如果用了
flask-static-digest等插件生成带哈希的文件名，Nginx 配置需支持通配：location ~ ^/static/.*\.[a-f0-9]{12,}\.(\w+)$ { ... }
真正容易被忽略的是：Gunicorn 启动命令里的模块路径（如 run:app）必须和实际文件结构完全匹配，大小写、子包层级、入口文件名一个都不能错；而 Nginx 的 proxy_pass 地址一旦写成 http://localhost:8000，在某些系统 DNS 配置下可能触发额外解析延迟，坚持用 127.0.0.1 最稳妥。
