在 django 自定义 user 模型中，若将 username 设为 primary_key，直接赋值修改后调用 save() 会触发新建记录行为，导致唯一约束冲突；应避免以业务字段作主键，并优先使用 queryset.update() 或重写 save() 逻辑来安全更新。
在 django 自定义 user 模型中，若将 username 设为 primary_key，直接赋值修改后调用 save() 会触发新建记录行为，导致唯一约束冲突；应避免以业务字段作主键，并优先使用 queryset.update() 或重写 save() 逻辑来安全更新。
Django 的 ORM 在处理模型实例保存时，会根据主键（pk）是否存在来判断是执行 INSERT 还是 UPDATE。当 username 被设为 primary_key=True 时，修改该字段再调用 userobj.save()，Django 会认为这是一个主键变更——而 Django 不支持原地更新主键值，其底层行为等价于：删除旧记录 + 插入新记录（即 INSERT ... ON CONFLICT 未启用，且无显式事务控制）。这正是你遇到 UNIQUE constraint failed: data_app_user.email 错误的根本原因：系统试图插入一条 username 不同但 email 相同的新记录，违反了 email 的唯一性约束。
✅ 正确实践：分离主键与业务标识字段
推荐方案是引入独立的、不可变的主键（如自增 id 或 UUID），让 username 回归其语义本质——一个可编辑的业务标识符：
from django.contrib.auth.models import AbstractBaseUser
from django.core.validators import EmailValidator
from django.db import models
class User(AbstractBaseUser):
# ✅ 推荐：使用自增整数或 UUID 作为主键
id = models.AutoField(primary_key=True) # 或 models.UUIDField(default=uuid4, primary_key=True)
# ✅ username 不再是主键，仅保持唯一性约束
username = models.CharField(max_length=30, unique=True)
full_name = models.CharField(max_length=65, null=True, blank=True)
email = models.EmailField(
max_length=255,
unique=True,
validators=[EmailValidator()]
)
# ⚠️ 必须显式定义 USERNAME_FIELD 和 REQUIRED_FIELDS
USERNAME_FIELD = 'username'
REQUIRED_FIELDS = ['email']
# ... 其他必要方法（如 get_full_name, has_perm 等）完成迁移后，即可安全更新 username：
# ✅ 安全方式 1：使用 QuerySet.update()（高效、原子、绕过模型层验证） User.objects.filter(username='old_username').update(username='new_username') # ✅ 安全方式 2：获取实例 → 修改 → 保存（需确保 pk 未被修改） user = User.objects.get(username='old_username') user.username = 'new_username'.lower() user.save() # 此时仅触发 UPDATE，因 id 未变
⚠️ 注意事项与最佳实践
- 不要在生产环境直接修改主键字段：即使技术上可行（如手动执行 SQL），也会破坏外键引用、审计日志、缓存键一致性等。
- update() 方法的局限性：它跳过模型的 save() 方法、信号（pre_save/post_save）、以及字段级验证（如 clean()）。如需完整生命周期钩子，请改用实例 .save()。
- 批量更新需谨慎：QuerySet.update() 不触发单个对象的 save()，若依赖 save() 中的逻辑（如密码哈希、时间戳更新），应改用循环+.save()（并考虑事务封装）。
- 迁移兼容性：若已有数据，需通过 makemigrations --empty 编写自定义迁移，添加 id 字段、填充初始值、设置主键，并移除 username 的 primary_key=True 属性。
总结
核心原则是：主键应稳定、不可变、无业务含义；业务字段（如 username、email）应通过唯一约束保障数据完整性，而非承担主键职责。遵循这一设计，既能保证数据操作的安全性，又能充分发挥 Django ORM 的更新语义优势。
