Django迁移中--fake-initial和--fake有什么区别？使用虚假迁移有哪些危险？有人知道吗？非常感谢大家。
我正在使用django 1.10
那么文档对此非常清楚
如果所有具有该迁移中所有CreateModel操作创建的模型名称的数据库表已存在，则允许Django跳过应用程序的初始迁移。此选项适用于首次针对预先存在使用迁移的数据库运行迁移时使用。但是，此选项不会检查匹配的表名称之外的匹配数据库架构
你问的是风险，这就是它
只有在您确信现有架构与初始迁移中记录的架构匹配时，才能安全使用。
告诉Django将迁移标记为已应用或未应用，但没有实际运行SQL来更改数据库架构。
这适用于高级用户在手动应用更改时直接操作当前迁移状态;
再一次明确突出风险
请注意，使用--fake会冒着将迁移状态表置于需要手动恢复以使迁移正确运行的状态的风险。
这个答案不仅适用于django 1.8+版本，也适用于其他版本。
编辑2018年11月：我有时会在这里和其他地方看到答案，这些答案表明你应该放弃你的数据库。这几乎不是正确的事情。如果丢弃数据库，则会丢失所有数据。
@ e4c5已经就这个问题给出了答案，但我想补充一点关于何时使用--fake和--fake-initial。
假设您有一个来自生产的数据库，并且您希望将其用于开发并应用迁移而不会破坏数据。在那种情况下，--fake-initial派上用场。
--fake-initial将强制Django查看您的迁移文件，并基本上跳过已创建数据库中的表。但请注意，将运行任何不创建表（而是修改现有表）的迁移。
相反，如果现有项目包含迁移文件，并且要重置现有迁移的历史记录，则通常使用--fake。
简短的回答
--fake不适用迁移--fake-initial可能不适用迁移更长的回答：
--fake：Django保留了一张名为django_migrations的表，以了解它过去应用了哪些迁移，以防止您再次意外地应用它们。所有--fake都会将迁移文件名插入到该表中，而不实际运行迁移。如果您先手动更改数据库架构，稍后再更改模型，并希望绕过django的操作，这将非常有用。但是，在该步骤中您自己是独立的，因此请注意不要以不一致的状态结束。
--fake-initial：取决于数据库的状态
--fake类似。只检查表的名称，而不是它们的实际模式，因此，请再次注意请注意，如果迁移文件在其类中具有--fake-initial，则仅考虑initial=True，否则将忽略该标志。此外，这是initial=True在迁移中唯一记录的用法。