Gunicorn启动Django访问Admin报relation "user"不存在错误

python manage.py runserver访问正常，说明代码逻辑、数据库表结构本身没问题。Gunicorn启动报relation "user" does not exist，核心原因是Gunicorn进程的运行环境和你执行runserver的shell环境不一致：你settings.py里的数据库配置全靠读os.environ拿连接参数，Gunicorn启动时没拿到DATABASE_NAME、DATABASE_USER这些环境变量，连到了错误的数据库（要么是默认的空Postgres库，要么是其他没执行过迁移的数据库实例），这个库里根本没有user表，自然报500。

• 先验证环境变量问题：手动在终端启动Gunicorn前，先执行echo $DATABASE_NAME，如果输出为空，说明当前shell没加载环境变量。先source你存放环境变量的文件（比如项目根目录的.env、虚拟环境activate脚本、/etc/profile下的全局配置），确认所有数据库相关环境变量都能正常打印后，再启动Gunicorn测试。
• 如果你是用Systemd配置Gunicorn开机自启（90%的人踩这个坑）：
  • 打开Gunicorn的service配置文件（默认路径/etc/systemd/system/gunicorn.service）
  • 在[Service]段落里确认两个配置：
    1. WorkingDirectory必须指向你项目的根目录（就是manage.py所在的文件夹，写绝对路径）
    2. 加一行EnvironmentFile=你项目.env文件的绝对路径，注意.env文件里的变量直接写DATABASE_NAME=xxx格式，不要加export前缀
  • 保存后依次执行systemctl daemon-reload、systemctl restart gunicorn重载配置重启服务
• 确认操作一致性：执行python manage.py migrate的用户、虚拟环境，要和启动Gunicorn的用户、虚拟环境完全一致，不要用root执行完迁移，切普通用户启动Gunicorn连错库。
• 顺便修个代码里的隐藏bug：你的registration.models.py里User模型的save方法，判断用了self.ADMIN，但类里只定义了A/I/C三个常量，根本没ADMIN这个属性，后续创建修改用户会直接抛错，把self.ADMIN改成self.A就行。
• 最后校验：重启Gunicorn后，先执行python manage.py dbshell进去执行\dt看表列表，确认能看到user表，再访问Admin后台即可。

内容的提问来源于stack exchange，提问作者wizard