当将 Django 1.4 的旧数据库迁移到 Django 5+ 时，因默认主键类型从 AutoField（INT）升级为 BigAutoField（BIGINT），导致外键约束创建失败。本文提供安全、可复现的四步修复方案，无需禁用约束或手动修改数据库。
当将 django 1.4 的旧数据库迁移到 django 5+ 时，因默认主键类型从 `autofield`（int）升级为 `bigautofield`（bigint），导致外键约束创建失败。本文提供安全、可复现的四步修复方案，无需禁用约束或手动修改数据库。
在 Django 5.0 及更高版本中，DEFAULT_AUTO_FIELD 默认值已更改为 "django.db.models.BigAutoField"，这意味着所有新模型的主键（如 id）在数据库中将被定义为 BIGINT 类型。而 Django 1.4 创建的旧表仍使用 INT（即 AutoField 对应的底层类型）。当你在新应用中定义一个外键指向该旧表（例如 models.ForeignKey(OldModel, on_delete=models.CASCADE)），Django 迁移系统会尝试让外键字段（如 field_id）也使用 BIGINT，从而与旧表的 INT 主键类型不一致，触发如下错误：
Column 'tbl1.id' is not the same data type as referencing column 'tbl2.field_id' in foreign key 'tb1_field_id_tbl2_id'
这不是数据库层面的兼容性问题，而是 Django 迁移引擎在生成 DDL 时严格校验列类型所致。
✅ 正确解决方案：统一回退到 AutoField
关键在于全局对齐主键类型策略，而非局部绕过约束。以下步骤经生产环境验证，安全可靠：
-
全局配置降级默认主键类型
在项目settings.py中显式设置：DEFAULT_AUTO_FIELD = "django.db.models.AutoField"
-
逐应用覆盖默认配置
对每个已存在的 Django 应用（尤其是包含旧模型的应用），编辑其apps.py文件，确保default_auto_field显式指定为AutoField：# myapp/apps.py from django.apps import AppConfig class MyappConfig(AppConfig): default_auto_field = "django.db.models.AutoField" # ← 关键！ name = "myapp"并在
__init__.py或settings.INSTALLED_APPS中确认使用了该配置类（如'myapp.apps.MyappConfig'）。
Django Unfold下载提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
彻底清理迁移历史
删除 所有应用下的migrations/目录内容（保留空目录和__init__.py），包括__pycache__和.pyc文件。⚠️ 注意：此操作仅影响迁移文件，不触碰现有数据库表结构。-
分阶段重建迁移
- 首先，暂不包含新外键模型，运行：
python manage.py makemigrations python manage.py migrate
此步将为现有旧模型生成兼容
AutoField的迁移（实际为空操作，但重置迁移状态）。 - 然后，在模型文件中加入你的新模型（含外键），再执行：
python manage.py makemigrations python manage.py migrate
此时 Django 将为外键字段生成
INTEGER类型（而非BIGINT），与旧表id类型完全一致，外键约束成功创建。
- 首先，暂不包含新外键模型，运行：
⚠️ 重要注意事项
-
db_constraint=False是临时规避，非解决：它跳过数据库级外键约束，丧失参照完整性保障，不推荐用于生产环境。 -
不要仅修改
to_field或db_type：Django 不允许直接干预外键列的数据类型；to_field="id"仅指定关联字段名，不改变类型。 -
避免混合
BigAutoField与AutoField：同一数据库中混用会导致未来新增关系再次报错，必须全局统一。 -
验证迁移 SQL（可选）：执行前可用
python manage.py sqlmigrate app_name 0001检查生成的CREATE TABLE语句，确认外键列为integer而非bigint。
通过以上流程，你既保留了完整的数据库约束能力，又实现了新旧 Django 版本间的平滑兼容。核心思想是：让新模型“向后兼容”，而非强迫旧数据“向前升级”。
