嘿，我正好碰到过几乎一模一样的场景，咱们一步步拆解这个问题，给你最贴合Django规范的解决方案：

先解答你的核心疑问 #

• 迁移会不会失败？ 直接修改TextChoices后执行makemigrations和migrate，迁移本身不会失败——因为Django只会更新模型的元数据，不会自动修改数据库里的存量数据。但问题在于，数据库里的旧值（比如'Contacted'）不再属于新的枚举选项集合，后续会触发验证错误。
• Admin/API会不会崩？ 会的！比如在Admin里编辑旧数据时，Django会尝试把数据库里的'Contacted'映射到新的枚举选项，找不到匹配项就会抛出ValidationError；如果用了DRF序列化器，也会因为值不在合法choices里而报错。

最安全、符合Django规范的分步解决方案 #

这个方案能保证跨环境（dev/staging/prod）同步，且全程不破坏服务：

步骤1：先兼容旧值，新增枚举选项 #

先不要删除旧的枚举项，而是保留旧值同时添加新选项，让新旧值都处于合法状态：

class ClientStatus(models.TextChoices):
    # 保留旧枚举，确保存量数据通过验证
    CONTACTED = "Contacted"
    BOOKED = "Booked"
    # 新增更新后的枚举选项
    CONTACTED_FOR_ASSESSMENT = "Contacted for assessment", "Contacted for assessment"
    ASSESSMENT_BOOKED = "Assessment booked", "Assessment booked"

执行python manage.py makemigrations和migrate，这一步只会更新模型的choices配置，不会改动数据库数据，此时Admin和API都能正常处理新旧状态值。

步骤2：生成数据迁移，批量更新存量数据 #

运行以下命令生成空迁移文件：

python manage.py makemigrations --empty your_app_name

打开生成的迁移文件，添加批量更新数据的逻辑：

from django.db import migrations

def update_client_status(apps, schema_editor):
    # 获取历史版本的模型（不能直接导入当前模型，避免迁移时的依赖问题）
    Client = apps.get_model('your_app_name', 'Client')
    # 批量替换旧值为新值
    Client.objects.filter(current_status='Contacted').update(current_status='Contacted for assessment')
    Client.objects.filter(current_status='Booked').update(current_status='Assessment booked')

class Migration(migrations.Migration):
    dependencies = [
        ('your_app_name', '之前的迁移文件名'),  # 比如0003_previous_migration
    ]

    operations = [
        migrations.RunPython(update_client_status),
    ]

执行python manage.py migrate，这会把数据库里的所有旧状态值批量更新为新值。

步骤3：移除旧枚举选项 #

等所有数据都更新完成后，再删除旧的枚举项，只保留新的配置：

class ClientStatus(models.TextChoices):
    CONTACTED_FOR_ASSESSMENT = "Contacted for assessment", "Contacted for assessment"
    ASSESSMENT_BOOKED = "Assessment booked", "Assessment booked"

再次执行makemigrations和migrate，这一步只会更新模型的choices，不会影响数据（因为数据库里已经没有旧值了）。

关于手动SQL的问题 #

手动SQL确实能快速解决数据更新问题，但非常不推荐，原因有：

• 跨环境同步麻烦：dev环境执行后，staging和prod还要手动重复操作，容易遗漏或写错
• 脱离Django迁移体系：后续团队成员查看迁移历史时，看不到这次数据变更的记录，不利于维护
• 风险高：如果WHERE条件写错，可能会批量更新错误数据，且很难回滚

如果一定要用手动SQL，务必先备份数据，并且配合前面的兼容步骤（先加新枚举，执行SQL，再删旧枚举）。

额外注意事项 #

• 测试：在dev环境完整走一遍流程，验证数据更新正确、Admin和API无报错
• 序列化器：如果用了DRF序列化器，确保序列化器的choices同步更新，或者直接引用模型的choices
• 缓存：如果有缓存用户状态的逻辑，记得清空缓存，避免旧值残留

内容来源于stack exchange