dumpdata导出需按外键依赖顺序显式指定模型，loaddata要求fixture置于fixtures/目录且文件名合法，json时间字段须保持iso格式，导入后需重置主键序列。
dumpdata导出时模型顺序错乱导致loaddata失败
导出数据时如果不指定模型顺序，dumpdata 默认按应用注册顺序输出，但 loaddata 要求外键依赖必须前置——比如 User 必须在 Profile 之前，否则报 IntegrityError: insert or update on table "xxx" violates foreign key constraint。
实操建议：
- 显式列出所有模型，并按依赖关系从上到下排序：
python manage.py dumpdata auth.user contenttypes --indent=2 > base.json - 用
--natural-foreign避免主键硬依赖（需模型实现natural_key()） - 跳过中间表或历史表：加
--exclude auth.permission --exclude contenttypes，减少冗余和冲突
loaddata导入时提示“no fixture named xxx found”
这不是路径问题，而是 Django 对 fixture 文件名和格式有隐含约定：文件必须放在 fixtures/ 子目录下，且扩展名只能是 .json、.xml 或 .yaml；同时文件名不能含大写字母或特殊符号，否则 loaddata 直接忽略。
常见错误现象：
-
python manage.py loaddata ../data/export.json→ 报错“no fixture named export found” -
python manage.py loaddata my_data.json→ 同样失败，因为没在fixtures/目录里
正确做法：
- 把文件放进任一已注册 app 的
fixtures/目录（如myapp/fixtures/export.json） - 运行
python manage.py loaddata export（不带扩展名，也不带路径） - 若要跨目录加载，用绝对路径加
--format=json：python manage.py loaddata /tmp/export.json --format=json
JSON导出后时间字段变成字符串，loaddata时无法反序列化
Django dumpdata 输出的 JSON 中，DateTimeField 和 DateField 默认转成 ISO 格式字符串（如 "2024-05-12T10:30:00.123Z"），这本身没问题；但如果你自定义了 JSONEncoder 或用了第三方序列化器，可能破坏格式，导致 loaddata 解析失败并静默跳过该条记录。
关键点：
- 不要手动修改 dump 出的 JSON 时间字段——Django 期望标准 ISO 8601 格式
- 检查是否启用了
USE_TZ = True：若开发环境关了时区，而生产开了，dump 出的时间可能缺Z或带本地偏移，loaddata会拒绝解析 - 验证 JSON 合法性：
python -m json.tool export.json > /dev/null，报错说明格式被改坏
迁移数据时忽略迁移历史表导致后续 migrate 失败
dumpdata 默认不导出 django_migrations 表，这是对的；但如果你用 loaddata 导入了旧数据，又没同步迁移记录，下次执行 migrate 就可能重复运行已执行过的迁移，或跳过应运行的迁移。
真正要做的不是导出迁移表，而是：
- 导入前确认目标库的
django_migrations状态和源库一致（可用SELECT * FROM django_migrations ORDER BY app, name;对比） - 如果只是复制生产数据到测试环境，导入后手动补上缺失的迁移记录（仅限可信场景）：
python manage.py migrate --fake-initial或--fake - 避免用
loaddata替代迁移：它不触发post_migrate信号，也不重建索引、约束，仅做原始插入
最易被忽略的一点：dump 出的 JSON 里没有数据库自增 ID 的当前值，loaddata 插入后，新记录可能撞上已有主键——记得导入后重置序列（PostgreSQL）或自增计数器（MySQL）。
