循环依赖报错是Django迁移依赖图检测到闭环，如app_a.0001_initial依赖app_b.0002_add_field而后者又反向依赖前者，常见于跨App外键或GenericForeignKey中硬编码未就绪模型引用。
循环依赖报错的典型现象是 Circular dependency detected
这不是语法错误，而是 Django 在解析迁移依赖图时发现闭环：比如 app_a.0001_initial 依赖 app_b.0002_add_field，而后者又反向依赖前者。常见于跨 App 的外键、GenericForeignKey 或自定义迁移中硬编码了未就绪的模型引用。Django 会直接中断 makemigrations 或 migrate，不给出具体哪两行代码导致，只抛出这个提示。
调整 INSTALLED_APPS 加载顺序不一定有效
Django 迁移依赖图基于模型定义和迁移文件内容，不是按 INSTALLED_APPS 顺序执行导入。把 A 放在 B 前面，不能解决 A 模型里引用 B 模型、B 模型里又引用 A 模型的问题。强行调换顺序可能掩盖问题，但下次加个新字段仍会爆。
- 仅当两个 App 完全无模型级交叉引用，只是迁移文件里写了错误的
dependencies = [('b', '0001')]时，重排INSTALLED_APPS才可能绕过（但属于治标） - 更常见的是：你改了
app_b/models.py，新加了一个指向app_a.UserProfile的外键，但app_a的迁移还没生成或没应用，Django 就卡在依赖检查阶段 - 此时应优先检查
showmigrations输出，确认哪些 App 的迁移处于[ ]（未应用）状态
用字符串代替模型类引用才是根本解法
Django 所有涉及模型引用的字段都支持字符串形式，它会延迟到运行时才解析，从而跳过导入时的循环。这是官方推荐做法，不是权宜之计。
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
-
ForeignKey("auth.User")而不是ForeignKey(User)（尤其当你没 import User 时） -
ForeignKey("myapp.MyModel")而不是ForeignKey(MyModel)，哪怕MyModel在同一个 app 内 -
GenericForeignKey("content_type", "object_id")不需要改，但其关联的ContentType引用也建议用"contenttypes.ContentType" - 注意字符串格式：必须是
"app_label.ModelName"，大小写敏感，不能带模块路径
迁移文件里已有循环依赖，怎么救
如果已经生成了含循环引用的迁移文件（比如 0003_auto_xxx.py 里手动写了 from app_b.models import X），别硬改。直接删掉它，再重新生成：
- 删掉出问题的迁移文件（保留
__init__.py） - 运行
python manage.py makemigrations --empty myapp创建空迁移 - 在空迁移的
operations里，用字符串写所有模型引用，例如：migrations.AddField( model_name='order', name='appointment', field=models.ForeignKey(to='appointment.Appointment', on_delete=models.CASCADE), ), - 再跑
python manage.py migrate
最易被忽略的一点：循环依赖往往不是孤立的，它常伴随未应用的前置迁移。务必先执行 python manage.py showmigrations，把所有 [ ] 状态的迁移补全，再处理当前报错的迁移。否则修完一个，下一个立刻报同样的错。