gunicorn启动即退出的主因是环境、路径、权限未对齐；需确保入口模块可导入、显式指定--bind/--chdir/--user参数、systemd中路径与pythonpath正确设置。
直接用 gunicorn 命令跑起来不难，难的是它一启动就退出、日志里只有一行 No module named 'app' 或 Address already in use——这不是配置错了，是环境、路径、权限三者没对齐。
确认入口模块能被 Python 正确导入
Gunicorn 不会自动切换到你的项目目录，也不会帮你激活虚拟环境。它只做一件事：按你给的模块路径，调用那个可调用对象（比如 app）。
- 先在项目根目录下手动测试：
python -c "from app import app"必须不报错；如果入口文件在src/app.py，就得改成python -c "from src.app import app" - 别留
if __name__ == '__main__': app.run()——Gunicorn 完全不走这个分支，留着反而干扰调试 - 确保当前 shell 已激活虚拟环境：
source venv/bin/activate，再装gunicorn，否则pip install gunicorn会装进系统 Python
启动命令必须带这三个参数
少一个，服务就只是“看起来在跑”，实际无法响应请求或根本起不来。
-
--bind必须显式指定：生产环境优先用 Unix socket，例如--bind unix:/tmp/myapp.sock；若临时调试用端口，至少写成--bind 127.0.0.1:8000，别用0.0.0.0:8000暴露到公网 -
--chdir必须设为项目根目录，例如--chdir /var/www/myflaskapp，否则gunicorn找不到静态文件、模板或requirements.txt -
--user和--group必须是非 root 用户，例如--user www-data --group www-data，否则 Nginx 无法读取 socket 文件，报Permission denied
systemd 服务文件里最常错的三处路径
写完 .service 文件后 systemctl start 失败，90% 出在这三处。
-
WorkingDirectory必须是项目根目录（如/var/www/myflaskapp），不是虚拟环境路径，也不是src目录 -
ExecStart必须用绝对路径调用虚拟环境里的gunicorn，例如/var/www/myflaskapp/venv/bin/gunicorn，不能只写gunicorn - 必须显式设置
Environment=PYTHONPATH=/var/www/myflaskapp，否则子进程导入模块时路径不对
Unix socket 权限、Nginx 的 user 配置、www-data 用户是否真有读 socket 的权限——这些细节不验证，前面所有步骤都白搭。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
