如何从旧Django迁移文件中移除废弃代码且避免数据库问题

嘿，这个问题我之前处理过好几次，别担心，只要按步骤来，不会搞砸数据库的。下面是具体的操作流程和注意事项：

1. 先明确迁移文件的状态 #

首先你得搞清楚哪些迁移已经应用到数据库，哪些还没有。运行这个命令查看：

python manage.py showmigrations

前面带有[X]的就是已经被应用的迁移，这类文件绝对不能随便修改或删除——Django靠这些文件的历史来跟踪数据库的状态一致性。

2. 处理已应用的旧迁移文件 #

如果被引用的函数在已经应用的迁移里，别直接改迁移文件！正确的做法是：

• 把这个“死代码”函数移到一个专门的遗留代码模块里，比如创建myapp/legacy.py，把函数挪过去。
• 修改旧迁移文件里的导入语句，指向这个遗留模块，比如把from myapp.models import my_old_function改成from myapp.legacy import my_old_function。
• 这样既清理了主代码目录的冗余，又保证了Django在检查迁移历史时能找到依赖的函数，不会抛出导入错误。

3. 处理未应用的迁移文件 #

如果这个迁移还没被任何环境（本地、测试、生产）应用过：

• 直接修改迁移文件，删除对该函数的引用，或者替换成等效逻辑（比如如果函数是生成默认值，要确保新逻辑和旧的输出一致）。
• 如果这个迁移是刚生成还没提交到团队仓库，甚至可以直接删除它，重新运行python manage.py makemigrations生成新的迁移文件——但要确保团队里没人已经应用过这个迁移，不然会造成历史冲突。

4. 长期方案：合并旧迁移（适合历史冗余多的情况） #

如果你的应用有大量老旧迁移，想彻底清理历史，可以合并迁移：

1. 先备份数据库（这一步绝对不能省！）
2. 将需要合并的旧迁移文件移到临时目录（别直接删除，留作备份）
3. 生成一个空的迁移文件：

   python manage.py makemigrations --empty myapp
   

4. 手动将合并后的数据库结构逻辑写入这个空迁移（可以用python manage.py sqlmigrate myapp <迁移编号>导出旧迁移的SQL，合并后整理成迁移代码）
5. 运行--fake命令告诉Django数据库已经处于该迁移的状态：

   python manage.py migrate --fake myapp
   

6. 同步这个新迁移到所有环境，之后就可以删除那些旧的迁移文件了。

关键注意事项 #

• 生产环境操作前必须备份数据库，哪怕你觉得万无一失。
• 团队协作时，一定要和队友同步迁移文件的修改，避免有人本地应用了旧版本迁移导致冲突。
• 如果函数是迁移中RunPython操作的一部分，要确认该操作已经执行过（数据库里数据已经更新），再处理——这类操作的代码必须保留到迁移历史里，直到你合并迁移为止。

内容的提问来源于stack exchange，提问作者fizzbuzzzzz