Django基础教程（二十）初识 Django QuerySet之添加记录：Django初战告捷！给数据库“塞”条记录，竟有这么多骚操作？-优快云博客

嘿，伙计们！今天咱们来聊点Django里最实在，也是你几乎每天都要打交道的东西——给数据库添加记录。

别看这事儿简单，就像往一个空本子里写第一行字。但你可曾想过，这笔是圆珠笔、钢笔还是键盘？是一笔一划地写，还是直接复制粘贴一大段？不同的姿势，背后可是天差地别的效率和哲学。

今天，咱就抛开那些官方文档的严肃脸，用最接地气的方式，把Django QuerySet里“添加记录”这回事儿，扒得底裤都不剩！

第一幕：初来乍到，你的第一个“Hello, World!”

在开始“添加”之前，咱得先有个“家”来安放数据，对吧？这个家，就是Django的模型。

假设我们正在搭建一个超简易的博客系统，首要任务就是管理文章。那么，一个Article模型应运而生。

# models.py
from django.db import models

class Article(models.Model):
    # CharField 用于存储较短字符串，比如标题
    title = models.CharField(max_length=200)
    # TextField 用于存储大段文本，比如正文
    content = models.TextField()
    # DateTimeField 用于存储日期和时间，auto_now_add=True 表示创建时自动设置为当前时间
    created_at = models.DateTimeField(auto_now_add=True)
    # IntegerField 用于存储整数，比如阅读量，默认给0
    views = models.IntegerField(default=0)

    def __str__(self):
        return self.title

代码白话文解说：

我们定义了一个Article类，它继承自models.Model。在Django里，这就是告诉框架：“嘿，这是个数据模型！”
title、content这些就是字段，相当于数据库表的列。
auto_now_add=True是个懒人神器，创建记录时自动打上时间戳，妈妈再也不用担心我忘记记录发布时间了。
__str__方法是个“美化师”，它决定了当我们打印一个文章对象时，显示的是有意义的标题，而不是冷冰冰的<Article: Article object (1)>。

好了，数据库的“毛坯房”建好了。接下来，咱们就要开始往里“搬家具”（添加数据）了。

第二幕：闪电战——`create()`方法，快就一个字！

如果你是急性子，想用最少的代码、最快的速度创建一条记录，那么create()就是你的天选之子。

它直接通过模型的管理器（默认是objects）调用，一步到位，无需“显式”保存。

# 在views.py、shell或任何你能调用Django代码的地方

from myapp.models import Article # 记得从你的app导入模型

# 使用 create() 方法，一步创建并保存
new_article = Article.objects.create(
    title='我的第一篇Django文章',
    content='哇，原来用Django添加记录这么简单！感觉马上就要走上人生巅峰了！',
    # created_at 会自动添加，所以我们不用管
    views=10
)

# 打印一下看看
print(new_article.title) # 输出：我的第一篇Django文章
print(new_article.id)    # 大概率输出：1 (数据库自动生成的主键ID)

create()的骚操作解析：

一气呵成：从创建对象到存入数据库，一条命令搞定。背后它其实也调用了save()方法，但帮你封装好了。
直接返回对象：create()执行成功后，会直接把创建好的、带着新鲜ID的对象返回给你，你可以立刻用它做别的事情。
适用场景：当你明确知道所有字段的值，并且想快速创建单条记录时，用它准没错。简单、粗暴、有效！

第三幕：经典咏流传——`save()`方法，细嚼慢咽的掌控感

如果说create()是外卖，那save()就是自己下厨。你先得去菜市场（创建对象实例），然后回家洗菜切菜（修改属性），最后开火烹饪（调用save()）。

# 第一步：创建模型的一个实例（对象），此时还在内存里，没进数据库
another_article = Article()

# 第二步：给这个对象的各个属性赋值
another_article.title = ‘慢慢来，比较快’
another_article.content = ‘使用save方法，让我对创建过程有了更强的掌控感。我可以先准备好所有东西，再统一保存。’
another_article.views = 5

# 第三步：显式地调用 save() 方法，此时数据才真正写入数据库
another_article.save()

# 同样，保存后可以访问其id
print(f"新文章ID是： {another_article.id}")

save()的细嚼慢咽哲学：

分步操作，逻辑清晰：创建、赋值、保存，三步走。特别适合在复杂的业务逻辑中，你可能需要根据一些条件来判断最终是否要保存这个对象。
更强的掌控力：你可以在调用save()之前，对对象进行多次修改。比如，先创建一个草稿，等用户确认后再保存。
别忘了最后一步！：新手常犯的错误就是忘了写.save()，然后一脸懵逼地问：“我数据呢？我明明赋值了啊！” 记住，不save()，数据就只在内存里，程序一重启就没了。

第四幕：性能核弹——`bulk_create()`，拯救你的服务器于水火

现在，请想象一个魔鬼场景：你需要从一份Excel表格里导入10000篇文章到你的博客系统。

如果你用create()或者save()，会发生什么？
你会循环10000次，每次都和数据库进行一次“握手”（网络I/O）和“交谈”（数据库事务）。这相当于你为了搬10000块砖，开车往返家里和砖厂10000次……油费和过路费（服务器资源）直接爆炸！

此时，bulk_create()闪亮登场！它就是那辆一次能拉5000块砖的超级大卡车！

# 假设我们有一个文章数据列表
article_list = []
for i in range(1, 1001): # 我们创建1000篇测试文章
    article = Article(
        title=f‘批量创建的文章 {i}’,
        content=f‘这是第 {i} 篇通过bulk_create创建的文章内容，效率起飞！’,
        views=i * 10
    )
    article_list.append(article)

# 关键一步：使用 bulk_create 一次性提交
Article.objects.bulk_create(article_list)

# 搞定！数据库只需要进行1-2次交互，而不是1000次。

bulk_create()的性能碾压解析：

大幅减少数据库查询次数：它将成百上千个INSERT语句打包成一个或少数几个批量操作，极大地减轻了数据库的压力。
速度提升是数量级的：处理大量数据时，速度比循环create()快几十倍甚至上百倍。
注意事项（必看！）：

- 不触发信号：bulk_create默认不会发送Django的post_save等信号。
- 不返回带ID的对象：在某些数据库后端（如SQLite， PostgreSQL），如果模型有自增ID，默认情况下bulk_create后，这些对象的ID可能不会被设置。除非你使用batch_size参数并确保数据库支持。所以，如果你需要立刻使用这些记录的ID，要小心。
- 忽略某些默认值：不会调用模型的save()方法，所以像auto_now_add这种在save()中处理的字段可以正常工作，但其他在save()中设置的默认值可能不会。

什么时候用？ 当你需要插入海量数据，且对实时性、信号和立即获取ID没有严格要求时，请毫不犹豫地选择它！

终章：华山论剑 & 避坑指南

好了，三位主角已全部登场。我们来个总结性PK：

特性	`create()`	`save()`	`bulk_create()`
易用性	★★★★★	★★★★☆	★★★☆☆
灵活性	★★☆☆☆	★★★★★	★★☆☆☆
性能	单条，一般	单条，一般	海量，核弹级
适用场景	快速创建单条记录	需要分步控制创建过程	一次性导入大量数据

新手必踩的坑，我帮你填平了：

坑1：忘了 migrate
“老哥，我代码一模一样，为啥报错说表不存在？” 记住，每次你新增模型或者修改了模型字段，一定要执行两条魔法命令：

python manage.py makemigrations  # 生成“迁移计划书”
python manage.py migrate         # 执行“迁移计划”，真正建表或修改表结构

坑2：字段名写错
article.tittle = ‘...’ （少了个i）。运行时会得到一个AttributeError。Django模型可不会自动纠错哦。
坑3：违反字段约束
比如，你定义title = models.CharField(max_length=200)，结果你偏要赋一个300字符的字符串。数据库会毫不留情地给你一个异常。所以在保存前，最好对用户输入的数据进行验证。