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一致（即所有旧迁移均已成功执行）。
# 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； - 生产环境慎用：建议在预发布环境充分验证，并备份数据库后再操作。
通过这一标准流程，你不仅解决了“压缩后仍报变更”的表象问题，更重建了迁移系统的可信基线——让 Django 再次确信：“模型即数据库，迁移即真相”。
