本文详解如何在 Django 中通过 ForeignKey 将自定义模型（如交易记录 Entry）关联到内置 User 模型，解决因误用 to_field="username" 导致的迁移错误，并提供安全、可维护的一对多关系实践方案。
本文详解如何在 django 中通过 foreignkey 将自定义模型（如交易记录 entry）关联到内置 user 模型，解决因误用 `to_field="username"` 导致的迁移错误，并提供安全、可维护的一对多关系实践方案。
在 Django 中为用户专属数据（如交易日志）建立“一个用户对应多条记录”的关系，最标准且推荐的方式是使用 ForeignKey 关联 Django 内置的 User 模型——但必须关联到主键字段（默认为 id），而非 username 等非主键字段。你遇到的 ValueError: Field 'id' expected a number but got 'andredi15' 错误，正是由于在 ForeignKey 中错误指定了 to_field="username" 所致。
❌ 错误原因分析
你在 Entry 模型中这样定义了外键：
username = models.ForeignKey(
get_user_model(),
on_delete=models.CASCADE,
related_name="usernames",
to_field="username" # ⚠️ 危险！不要这么做
)
问题在于：
- to_field="username" 告诉 Django：该外键应引用 User.username 字段（类型为 CharField）；
- 但 Django 迁移系统在创建数据库约束时，仍会尝试将该字段映射为整数型外键列（因默认 ForeignKey 隐式依赖目标模型的主键类型），导致底层试图把字符串 'andredi15' 强转为 int，从而抛出 ValueError；
- 更重要的是：username 不是唯一可靠标识符（虽默认唯一，但语义上它不是主键），且一旦未来允许用户名修改或启用邮箱登录，此类设计将引发数据一致性风险。
✅ 正确做法：关联 id，并重命名字段为语义清晰的 user
只需两步修正：
- 移除 to_field 参数（默认自动关联目标模型的 pk，即 User.id）；
- 将字段名从 username 改为 user —— 更准确表达其含义（这是一个 User 实例，而非用户名字符串）。
修正后的 Entry 模型如下：
# models.py
from django.db import models
from django.contrib.auth import get_user_model
class Entry(models.Model):
# ... 其他字段保持不变 ...
# ✅ 正确：关联 User 模型的主键（id），字段名语义明确
user = models.ForeignKey(
get_user_model(),
on_delete=models.CASCADE,
related_name="entries", # 推荐：用复数形式，如 user.entries.all()
)
def __str__(self):
return f"{self.result} {self.entered_date}"
? 提示：related_name="entries" 比 "usernames" 更符合业务逻辑（用户拥有多个 entries），也避免与 User.username 字段名混淆。
? 视图层：确保每次创建/更新时绑定当前用户
在视图中，绝不能依赖表单提交的 user 字段（前端可篡改），而应显式赋值 request.user：
# views.py
from django.contrib.auth.decorators import login_required
from django.shortcuts import redirect, render
from .forms import EntryForm
from .models import Entry
@login_required
def entry_create_view(request):
if request.method == "POST":
form = EntryForm(request.POST, request.FILES)
if form.is_valid():
entry = form.save(commit=False)
entry.user = request.user # ✅ 强制绑定当前登录用户
entry.save()
return redirect("entry_list")
else:
form = EntryForm()
return render(request, "entries.html", {"form": form})
同理，在编辑视图中也需校验权限并显式设置：
@login_required
def entry_update_view(request, pk):
entry = get_object_or_404(Entry, pk=pk, user=request.user) # ✅ 权限校验：仅允许修改自己的记录
if request.method == "POST":
form = EntryForm(request.POST, request.FILES, instance=entry)
if form.is_valid():
form.save() # user 已在 instance 中，无需再设
return redirect("entry_detail", pk=pk)
else:
form = EntryForm(instance=entry)
return render(request, "single_entry.html", {"form": form, "entry": entry})
? 是否需要自定义 User 模型？
对于本项目（Trading Journal），完全不需要。Django 默认 User 模型已满足需求：
- ✅ id 主键稳定可靠，适合作为外键目标；
- ✅ username, email, first_name 等字段开箱即用；
- ✅ 认证、权限、管理后台全面支持；
- ❌ 自定义用户模型（AbstractUser 或 AbstractBaseUser）仅在需扩展核心字段（如手机号必填）、更改认证方式（如邮箱登录）或彻底重构用户结构时才推荐——它会显著增加复杂度和迁移成本。
✅ 最佳实践总结：
- 外键始终指向 User.id（省略 to_field 即可）；
- 字段命名为 user（非 username），语义清晰；
- related_name 使用复数（如 "entries"），便于反向查询；
- 视图中强制 entry.user = request.user，杜绝越权操作；
- 利用 get_object_or_404(..., user=request.user) 实现细粒度权限控制。
完成上述修改后，删除最近一次失败的迁移文件（如 0011_*.py），执行：
python manage.py makemigrations python manage.py migrate
即可成功应用关系变更。你的交易记录将严格归属且隔离于各用户账户之下。
