为何Django将业务逻辑硬编码至migrations中？

Django的迁移系统核心目标是保存模型的完整状态快照，而不仅仅是生成数据库DDL脚本——这是理解这个问题的关键。下面具体拆解原因：

• 迁移需要保证历史状态的可复现性
  当你回滚到某个旧版本的迁移时，Django需要还原当时模型的完整行为，而不只是数据库结构。比如upload_to决定了文件上传的路径生成逻辑，如果迁移里不硬编码这个逻辑，回滚时会直接使用当前models.py里的新逻辑，导致旧迁移对应的文件上传行为和当初不一致；同理，validators如果不被序列化进迁移，回滚后模型字段的验证规则会变成当前版本的，破坏了历史状态的一致性。

• 字段的完整定义需要被序列化
  Django的迁移系统会序列化模型字段的所有参数，而不只是那些影响数据库结构的参数。validators和upload_to是字段定义的一部分——它们描述了字段的行为约束和业务逻辑，迁移系统需要完整保存这些信息，才能保证在任何环境下运行迁移时，模型的行为和创建该迁移时完全一致。哪怕这些逻辑不生成SQL，它们也是模型状态的重要组成部分。

• DRY原则的取舍是设计权衡
  你提到的DRY问题确实存在，但这是Django为了迁移可靠性做出的 trade-off。如果迁移只保存数据库相关的信息，那么回滚、多环境同步时很容易出现模型行为不一致的问题。

解决改动导致迁移崩溃的办法 #

要避免重命名upload_to或修改validators导致项目崩溃，最好的方式是把这些逻辑抽离到单独的模块中，作为可复用的对象引用，而不是直接在models里写匿名函数或硬编码字符串：

比如，不要这么写：

# models.py
from django.db import models
from django.core.validators import RegexValidator

class MyModel(models.Model):
    file = models.FileField(upload_to="uploads/%Y/%m/%d")
    name = models.CharField(max_length=100, validators=[RegexValidator(r'^[a-z]+$')])

而是抽成独立模块：

# utils/field_utils.py
from datetime import datetime
from django.core.validators import RegexValidator

def generate_upload_path(instance, filename):
    return f"uploads/{datetime.now().strftime('%Y/%m/%d')}/{filename}"

NAME_VALIDATOR = RegexValidator(r'^[a-z]+$')

然后在models里引用：

# models.py
from django.db import models
from utils.field_utils import generate_upload_path, NAME_VALIDATOR

class MyModel(models.Model):
    file = models.FileField(upload_to=generate_upload_path)
    name = models.CharField(max_length=100, validators=[NAME_VALIDATOR])

这样，即使你修改generate_upload_path的内部逻辑，或者重命名时保持模块引用不变（比如用别名），迁移文件里序列化的是utils.field_utils.generate_upload_path这个引用，不会因为代码改动导致迁移无法运行。

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