django迁移未生效的主因是迁移状态与数据库实际状态脱节，即django_migrations表中存在记录但sql未执行；其次为app未正确注册或migrations目录缺失初始文件；此外mysql隐式限制也可能导致alter操作静默失败。
迁移命令跑完但 mysql 里字段没变，大概率不是代码写错了，而是 django 的迁移状态和数据库实际状态脱节了——它“以为”已经同步完了，其实根本没动表。
django_migrations 表里有记录，但数据库没改
Django 执行 migrate 时，只看 django_migrations 表里有没有对应迁移记录。如果记录存在，哪怕那条迁移根本没执行成功（比如中途报错、SQL 被跳过、ALTER TABLE 失败），它也会直接跳过。
- 用 MySQL 客户端查一下：
SELECT * FROM django_migrations WHERE app = 'your_app_name'; - 如果看到记录，但字段确实没加/没删，说明迁移文件被标记为“已执行”，实际却没生效
- 常见于手动改过迁移文件、或执行
migrate时遇到OperationalError但没留意错误就继续操作
makemigrations 提示 No changes detected，但模型明明改了
这不是模型没改，是 Django 没“认出”这个应用该生成迁移——它默认只扫描已注册进 INSTALLED_APPS 的 app，且要求 migrations 目录下至少有一个初始迁移文件（比如 0001_initial.py）。
- 确认
settings.py的INSTALLED_APPS包含你的 app 名（如'blog'，不是'blog.apps.BlogConfig'除非你显式配置了） - 检查
myapp/migrations/目录是否只剩__init__.py；如果其他 .py 文件被删了，Django 不会自动补0001_initial.py - 直接运行：
python manage.py makemigrations myapp（必须带 app 名），强制触发初始化 - 别依赖 IDE 自动保存或热重载——改完
models.py后，手动保存文件再运行命令
字段加了但 MySQL 表还是老样子
MySQL 对某些 ALTER 操作有隐式限制，尤其是涉及索引长度、字符集、或外键约束时，Django 生成的 SQL 可能被 silently 忽略或部分失败。
- 开 MySQL 日志（
general_log = ON）或在命令后加--verbosity=2：python manage.py migrate --verbosity=2，看它到底执行了哪条 SQL - 常见卡点：
Specified key was too long（UTF8MB4 下索引超长）、Duplicate column name（字段名重复）、Cannot add or update a child row（外键约束冲突） - 如果迁移卡在某一步，不要反复
migrate——先手动在 MySQL 里执行失败的 ALTER，再删掉django_migrations里那条记录，再跑一次
最危险的操作是直接删整个 migrations 文件夹：Django 会重建初始迁移，但如果你的表已有数据，0001_initial.py 里的 CreateModel 操作会直接报错“table already exists”。真要重来，得先清 django_migrations 记录，再删迁移文件，再 makemigrations ——顺序不能错。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
