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

Django 迁移压缩后模型变更未同步：原因分析与安全修复方案

Django 执行 squashmigrations 后仍提示“模型有未反映的变更”，本质是压缩迁移未覆盖当前模型状态与数据库结构的一致性校验，需通过 --fake-initial 重建初始迁移并确保模型、迁移文件、数据库三者对齐。

django 执行 `squashmigrations` 后仍提示“模型有未反映的变更”，本质是压缩迁移未覆盖当前模型状态与数据库结构的一致性校验，需通过 `--fake-initial` 重建初始迁移并确保模型、迁移文件、数据库三者对齐。

在 Django 项目中，squashmigrations 是一个重构型操作，而非同步型操作：它仅将历史迁移逻辑合并为单个新迁移文件（如 0001_squashed_0244_*.py），但不会自动更新模型定义与数据库结构之间的映射关系。你遇到的现象——showmigrations 显示新压缩迁移为未应用（[-]），而 migrate 却报“模型有未反映的变更”——正是典型的状态错位：Django 检测到当前 models.py 与已应用的数据库结构之间存在差异，但该差异并未被任何 已标记为已应用 的迁移所覆盖。

? 为什么 `squashmigrations` 后仍有变更被检测到？

根本原因在于：

squashmigrations mainapp 0244 生成的 0001_squashed_... 文件，其 dependencies 指向原始迁移链起点（通常是 0001_initial），且 replaces = ["0001_initial", ..., "0244_..."]；
但它不包含 initial = True 标志，也不声明该迁移等价于当前数据库实际状态；
因此，Django 运行 migrate 时发现：
✅ 数据库已存在 0001_initial 到 0244_... 的全部变更（即表结构已是最新）；
❌ 但 0001_squashed_... 尚未被记录为已执行（django_migrations 表无对应记录）；
❌ 同时，Django 对比 models.py 与数据库结构，发现字段类型、约束等细节（如 AlterField）虽已生效，却无迁移文件显式声明这些变更已被应用 → 触发警告：“changes not yet reflected in a migration”。

这解释了为何 makemigrations --dry-run 仍输出大量 ~ Alter field：Django 的迁移检测器基于 当前模型 vs 当前数据库结构 的 diff，而非 vs 某个迁移文件。只要数据库里没有 0001_squashed_... 的执行记录，它就认为这些变更“悬空”，需重新生成迁移。

✅ 安全、可回溯的修复方案（推荐）

⚠️ 前提：确认生产环境尚未应用该压缩迁移，且本地数据库结构与 models.py 一致（即所有旧迁移均已成功执行）。

Django
避免常见的 Django 错误——QuerySet 评估、N+1 查询、迁移冲突和 ORM 陷阱。

下载

# 1. 将原迁移链“标记为已回滚”（不改动数据库，仅更新 django_migrations 表）
python manage.py migrate mainapp zero --fake

# 2. 彻底清理旧迁移文件（保留 __init__.py！）
rm mainapp/migrations/0*.py
touch mainapp/migrations/__init__.py

# 3. 基于当前 models.py 生成全新的初始迁移（含 initial=True）
python manage.py makemigrations mainapp

# 4. 告诉 Django：“这张表结构就是 0001_initial 所描述的，无需执行 SQL”
python manage.py migrate mainapp --fake-initial

✅ 此流程结果：

showmigrations 显示 0001_initial [X]（唯一迁移，已标记为已应用）；
makemigrations 不再提示变更（模型 ↔ 数据库 ↔ 迁移三者完全对齐）；
全量迁移历史被压缩为单个权威入口，符合版本控制与团队协作规范。

? 为什么不直接 `--fake` 压缩迁移？

尝试 python manage.py migrate mainapp 0001_squashed_... --fake 看似快捷，但存在严重隐患：

压缩迁移的 dependencies 通常仍依赖 0001_initial，而该迁移在数据库中已有记录；
Django 会拒绝 --fake 一个 dependencies 中存在已应用迁移的文件（报 InconsistentMigrationHistory）；
即使绕过，后续 makemigrations 仍可能因依赖图混乱生成错误迁移。

? 关键注意事项

永远不要删除 __init__.py：否则 Django 无法识别 migrations 目录；
--fake-initial 仅适用于数据库结构已完全匹配初始迁移场景：它要求 0001_initial.py 中的 CreateModel/AlterField 等操作，与当前数据库真实结构 100% 一致；
团队协同前务必同步：执行上述操作后，需将新 0001_initial.py 提交至 Git，并通知所有成员先 git pull，再执行 migrate --fake-initial；
生产环境慎用：建议在预发布环境充分验证，并备份数据库后再操作。