Django创建Order/OrderItem对象时，为何用user_id/order_id而非模型字段名？

我们已经为订单（Order）和订单项（OrderItem）创建了Django模型，其中Order模型的关联用户字段名为user，OrderItem模型的关联订单字段名为order。但在视图层创建对象时，却使用user_id和order_id进行赋值，请问这一写法的原因是什么？

相关代码示例 #

Order模型片段 #

class Order(models.Model):
    user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name="order_user")

视图创建Order对象片段 #

order = Order.objects.create(
    user_id=user_id,
    # 其他字段赋值略
)

OrderItem模型片段 #

class OrderItem(models.Model):
    order = models.ForeignKey(Order, related_name="items", on_delete=models.CASCADE)

视图创建OrderItem对象片段 #

OrderItem.objects.create(order_id=order_id, product=item["product"], price=item["price"], quantity=item["qty"])

解答 #

这是Django ForeignKey字段的自动生成后缀字段特性导致的，核心原因和优势如下：

• 底层字段映射逻辑
  当你定义ForeignKey字段（比如user）时，Django会在数据库表中自动创建一个名为{字段名}_id的实际存储字段（比如user_id），用来保存关联对象的主键值。直接用user_id赋值，本质是直接操作数据库层面的存储字段，绕开了Django对关联对象的实例化过程。

• 性能优化
  如果用user=user_instance的方式赋值，Django需要确保传入的是合法的用户实例（如果是从数据库查询出来的实例，还会额外验证）；而用user_id=user_id的话，直接传入主键值，不需要查询或实例化关联对象，减少了数据库查询次数，提升了创建效率，尤其在批量创建或高并发场景下更明显。

• 场景适配性
  在视图中，我们经常直接拿到的是关联对象的主键ID（比如从URL参数、前端提交的表单数据中获取user_id），直接用{字段名}_id赋值，不需要先通过ID查询出对应的模型实例，简化了代码逻辑，避免了不必要的数据库查询。

• 功能等价性
  这两种写法在功能上完全等价：

  # 方式1：用实例赋值
  user = User.objects.get(id=user_id)
  order = Order.objects.create(user=user)
  
  # 方式2：用_id后缀字段赋值
  order = Order.objects.create(user_id=user_id)
  

  最终都会在数据库的order表中写入相同的user_id值，区别仅在于方式2省略了查询用户实例的步骤。

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