生产环境Django合并分支后遇ProgrammingError字段不存在问题求助

核心问题定位 #

问题本质是主分支的迁移记录与生产数据库的实际结构不匹配，或分支合并导致迁移文件逻辑冲突，进而触发字段不存在的报错。

具体解决步骤 #

1. 验证生产数据库的实际结构 #

直接登录生产数据库，确认目标字段是否真的缺失：

-- PostgreSQL 示例
SELECT column_name FROM information_schema.columns WHERE table_name = 'appname_table' AND column_name = 'field';
-- MySQL 示例
SHOW COLUMNS FROM appname_table LIKE 'field';

• 若字段不存在：说明迁移未正确执行，需手动补全字段后同步迁移记录
• 若字段存在：说明Django的迁移记录与数据库状态不一致，需修正迁移标记

2. 正确执行虚假迁移（同步迁移记录） #

之前的虚假迁移操作可能有误，按以下步骤执行：

• 先查看Django已记录的迁移状态：

  python manage.py showmigrations appname
  

• 找到对应新增字段的迁移文件（如00xx_add_field_to_table.py）：
  1. 若数据库无该字段，先手动添加（根据字段类型调整语句）：

     ALTER TABLE appname_table ADD COLUMN field VARCHAR(255) NULL;
     

  2. 标记该迁移为已执行：

     python manage.py migrate --fake appname 00xx
     

  注：00xx为迁移文件的编号，比如0003_add_field_to_table只需写0003

3. 修复合并后的迁移文件冲突 #

若分支合并时迁移文件出现冲突（如两个分支同时修改同一张表的迁移）：

• 本地用生产数据库备份重现问题，重新生成正确迁移：
  1. 将生产数据库备份导入本地测试库
  2. 拉取主分支代码，确保与生产环境一致
  3. 删除冲突的迁移文件，生成空迁移：

     python manage.py makemigrations appname --empty
     

  4. 手动编辑空迁移文件，写入功能分支里的字段添加逻辑
  5. 本地测试迁移无误后，推到生产执行：

     python manage.py migrate appname
     

4. 紧急临时恢复方案 #

若迁移执行卡死，先让应用恢复运行：

• 在Django模型中将该字段设为null=True，暂时注释掉依赖该字段的业务逻辑，待应用启动后再逐步修复迁移问题

后续预防措施 #

• 功能分支开发时，定期合并主分支的迁移文件，避免合并时出现大冲突
• 上线前必须在与生产结构一致的测试环境验证迁移执行
• 每次迁移前备份生产数据库

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