Django生产环境接入Google登录报socialaccount_socialapp_sites表不存在

django.db.utils.ProgrammingError: (1146, "Table 'main.socialaccount_socialapp_sites' doesn't exist")

在Django生产站点接入Google登录功能时，该功能在开发服务器运行完全正常，但部署到生产服务器后，即使执行python manage.py migrate命令仍触发上述报错。尝试删除所有迁移文件后重新执行makemigrations与migrate命令，问题仍未解决。

• 优先核对生产环境的INSTALLED_APPS配置，确认django.contrib.sites、django.contrib.auth、allauth、allauth.account、allauth.socialaccount全部完成注册。多数项目会拆分开发/生产两套配置文件，生产配置漏加前置应用是高频问题：socialaccount_socialapp_sites是allauth依赖sites框架生成的SocialApp和Site的多对多中间表，缺任意一个前置应用都不会触发该表的建表逻辑。
• 核查迁移执行的实际生效状态，不要默认migrate执行成功就代表所有表已建好。在生产环境执行以下命令查看对应应用的迁移执行记录：

  python manage.py showmigrations sites
  python manage.py showmigrations socialaccount
  

  如果返回的迁移项前存在[ ]标记的未执行条目，单独对对应应用执行迁移即可：

  python manage.py migrate sites
  python manage.py migrate socialaccount
  

• 确认生产环境命令执行的环境一致性。如果部署用了容器、多虚拟环境、多用户权限隔离，很容易出现migrate命令跑在其他Python环境、连错数据库的问题。可以直接在生产环境执行python manage.py dbshell进入当前服务连接的数据库命令行，手动查询库表：MySQL环境执行SHOW TABLES LIKE '%socialapp_sites%';，PostgreSQL环境执行\dt *socialapp_sites*，直接确认当前连接的库中是否存在目标表，排除迁移连错库的问题。
• 不要删除第三方应用自带的迁移文件重建。django-allauth、django.contrib.sites本身自带官方初始迁移文件，删除这类文件会打断迁移依赖链，导致建表逻辑异常。如果之前误删了第三方包的迁移文件，先重新安装对应版本的Django、django-allauth包恢复原生迁移文件，再执行python manage.py migrate --fake-initial跳过已存在表的重复创建逻辑，补全缺失的中间表。
• 检查生产配置中的SITE_ID参数是否正确配置，allauth的表关联逻辑强依赖该参数，参数配置错误会导致查表路径异常，触发误报表不存在的问题。

内容的提问来源于stack exchange，提问作者Taufiq Bin Abdul Rahman