当你运行迁移时，Django 正在使用存储在迁移文件中的模型的历史版本。如果你使用 RunPython 操作编写 Python 代码，或者你的数据库路由上有 ​allow_migrate ​方法，则你 需要使用 这些模型的历史版本而不是直接导入它们。

如果你直接导入模型而不是使用历史模型，则迁移 最初可能会工作 但将来在尝试重新运行旧迁移时会失败（通常，当你设置新安装并运行所有迁移时 以建立数据库时）。
这意味着历史模型的问题可能不会立即显现。如果遇到这种故障，可以编辑迁移以使用历史模型，而不是直接导入并提交这些更改。

因为不可能序列化任意的 Python 代码，这些历史模型不会有你定义的任何自定义方法。然而，它们将具有相同的字段、关系、管理器（仅限于那些具有 ​use_in_migrations = True​）和 ​Meta ​选项（也有版本控制，因此它们可能与当前的不同）。

这意味着在迁移中访问对象时，将不会对对象调用自定义的 ​save()​ 方法，也不会有任何自定义构造函数或实例方法。适当的计划一下吧！

字段选项中对函数的引用，例如 ​upload_to ​和 ​limit_choices_to ​以及具有 ​use_in_migrations = True ​的模型管理器声明，都会在迁移中序列化，因此只要有迁移引用它们，这些函数和类就需要保留。任何 自定义模型字段 也需要保留，因为这些都是直接由迁移导入的。
此外，模型的具体基类是以指针的形式存储的，所以只要有一个包含对它们的引用的迁移，你就必须始终将基类保留在身边。从好的方面来说，这些基类的方法和管理器都是正常继承的，所以如果你一定需要访问这些，你可以选择将它们移到一个父类中。
要删除旧的引用，你可以 压缩迁移 或者，如果引用不多，把它们复制到迁移文件中。