Django迁移报错：admin.0001_initial早于依赖userSocial.0001_initial执行

问题根源 #

你遇到的错误是因为自定义用户模型的迁移被admin应用的初始迁移依赖，但admin迁移已经提前执行。Django的admin、auth等核心应用默认依赖系统用户模型，当你新增自定义用户模型后，核心应用的迁移顺序被打乱，导致依赖冲突。

解决方案（保留第一个应用结构） #

1. 备份第一个应用的数据库结构（可选但推荐） #

先导出第一个应用的表结构，防止意外丢失：

pg_dump -d 你的数据库名 -s -n 第一个应用的schema > first_app_backup.sql

如果你的应用使用公共schema，去掉命令中的-n 第一个应用的schema即可。

2. 清理数据库中的冲突迁移记录与系统表 #

登录PostgreSQL数据库：

psql -U 你的数据库用户名 -d 你的数据库名

执行以下SQL操作：

• 仅保留第一个应用的迁移记录：

DELETE FROM django_migrations WHERE app NOT IN ('第一个应用的名称');

• 删除依赖用户模型的系统应用表（这些表会通过后续迁移重建）：

DROP TABLE IF EXISTS admin_log, auth_group, auth_group_permissions, auth_permission, django_content_type, django_session CASCADE;

操作完成后退出psql：\q

3. 重置新应用的迁移文件 #

• 保留第一个应用的migrations文件夹及所有文件，不要改动。
• 删除用户应用（userSocial）和社交应用的migrations文件夹内的所有迁移文件（仅保留__init__.py）。
• 重新生成新应用的迁移：

python manage.py makemigrations userSocial 社交应用名称

4. 按依赖顺序执行迁移 #

先迁移用户应用（解决admin的依赖问题），再执行全量迁移：

# 先迁移用户应用
python manage.py migrate userSocial
# 再迁移剩余所有应用
python manage.py migrate

5. 验证结果 #

启动项目后，检查第一个应用的表结构是否完整，新应用的用户、帖子、评论表是否正常创建，测试原有API功能是否正常。

补充说明 #

• 为什么migrate admin zero无效？因为admin迁移依赖auth应用，而auth又依赖用户模型，单独回滚admin无法打破整个依赖链的冲突。
• 此方案仅删除系统应用的表和迁移记录，第一个应用的表结构和迁移记录完全保留，无需重复开发。

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