Django 迁移压缩后仍检测到模型变更：原因分析与安全修复方案-Python教程-PHP中文网

Django 迁移压缩后仍检测到模型变更：原因分析与安全修复方案

Django squashmigrations 后 makemigrations 仍报告字段变更，本质是模型状态与压缩迁移文件未对齐——压缩仅合并历史SQL逻辑，不重置模型与迁移的“当前快照”一致性；需通过清空历史+重建初始迁移并配合 --fake-initial 安全修复。

django `squashmigrations` 后 `makemigrations` 仍报告字段变更，本质是模型状态与压缩迁移文件未对齐——压缩仅合并历史sql逻辑，不重置模型与迁移的“当前快照”一致性；需通过清空历史+重建初始迁移并配合 `--fake-initial` 安全修复。

? 问题根源：`squashmigrations` 不等于“重置迁移起点”

python manage.py squashmigrations mainapp 0244 的作用是*将 0001 到 0244 共 244 个迁移逻辑合并为一个新迁移文件（如 `0001_squashed0244.py）**，但它**不会修改你的当前模型定义（models.py`）**，也不会自动将该压缩文件标记为“已完全反映当前模型状态”。

关键点在于：

压缩迁移文件中的 operations 是从原 244 个迁移中提取、去重、排序后的历史操作集合；
但 Django 在运行 makemigrations 时，会将当前 models.py 的实际字段定义与数据库当前结构（或最后一次成功应用的迁移所描述的结构）进行比对；
若你在此前曾手动修改过 models.py（例如调整了 max_length、添加了 blank=True、变更了 related_name 等），而这些修改未被原始 0244 迁移完整覆盖（比如在最后几个迁移中遗漏、或被 --fake 过跳过），那么压缩后的迁移文件就无法准确描述“模型 → 数据库”的最终映射关系；
结果就是：showmigrations 显示压缩迁移为 [ - ]（未应用），但 migrate 拒绝执行（因无待应用变更），而 makemigrations --dry-run 却检测到差异——说明 Django 认为“模型 ≠ 当前数据库状态”，矛盾由此产生。

✅ 简单说：squashmigrations 是“归档旧账”，不是“刷新账本”。模型和数据库之间的“一致性契约”仍需你显式重建。

? 正确修复流程（推荐：安全、可复现、符合 Django 最佳实践）

以下步骤适用于开发/测试环境（严禁直接用于生产环境，必须先备份数据库！）：

✅ 步骤 1：伪造回滚至零点（清空迁移记录）

python manage.py migrate mainapp zero --fake

⚠️ 此命令不改动数据库表结构，仅在 django_migrations 表中删除 mainapp 下所有迁移记录，告诉 Django：“这些迁移我假装都没执行过”。

Django Unfold
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。

下载

✅ 步骤 2：彻底清理旧迁移文件（保留 `init.py`！）

# 进入 mainapp/migrations/
rm -f mainapp/migrations/0*.py
# 确保 __init__.py 仍存在（否则 Django 不识别 migrations 目录）
ls mainapp/migrations/__init__.py  # 应输出存在

✅ 步骤 3：基于当前模型生成全新初始迁移

python manage.py makemigrations mainapp

✅ 此时生成的 0001_initial.py 将精确反映你当前 models.py 的全部定义（包括所有字段类型、约束、关系等），不再依赖历史碎片。

✅ 步骤 4：伪造应用初始迁移（关键！）

python manage.py migrate mainapp --fake-initial

✅ --fake-initial 是 Django 专为此场景设计的安全机制：它要求——

数据库中已存在与 0001_initial.py 中 CreateModel/AlterField 等操作完全匹配的表结构（即你压缩前的数据库已是最终形态）；

且该迁移文件含 initial = True 标志（makemigrations 自动生成时默认包含）。
→ Django 仅向 django_migrations 插入一条记录，不做任何 DDL 操作，完美跳过重复建表风险。

验证结果：

python manage.py showmigrations mainapp
# 输出应为：
# mainapp
#  [X] 0001_initial

⚠️ 重要注意事项与避坑指南

风险点	说明	正确做法
生产环境误操作	直接 `--fake-initial` 可能导致结构错位	✅ 生产环境必须先用 `sqlmigrate mainapp 0001_initial` 导出 SQL，人工核对与线上表结构是否 100% 一致；必要时先备份再执行
忽略 `__init__.py`	删除后 `makemigrations` 无法识别 migrations 目录	✅ 清理时 `rm .py` 但绝不删 `__init__.py`*
多人协作未同步	团队成员未统一执行上述流程	✅ 将新生成的 `0001_initial.py` 提交至 Git，并在 PR 中明确标注“迁移已压缩，全员需执行 `migrate --fake-initial`”
混淆 `--fake` 和 `--fake-initial`	`--fake` 用于跳过任意迁移；`--fake-initial` 仅限首次接入已有数据库	✅ 本场景必须用 `--fake-initial`，不可替换为 `--fake`

? 总结：何时该压缩？何时该重来？

✅ 适合 squashmigrations：项目早期（RunPython、团队模型高度一致、仅需减小迁移文件数量。
✅ 必须重走 zero → makemigrations → --fake-initial：压缩后出现模型差异、涉及数据迁移逻辑、多人分支长期未同步、或你已不确定数据库真实结构来源。