Django 开发指南：深入理解 values() 与 values_list() 的差异及最佳实践

2026-01-31 23:37:01 0条评论 3次阅读 0人点赞

: 在 Django 开发的日常工作中，我们经常需要与数据库打交道。通常情况下，我们使用 Model.objects.all() 来获取数据，但这会返回完整的模型实例。当我们只需要模型中的某几个特定字段时，加载整个实例显然是对资源的浪费。这不仅增加了数据库的查询负载，还会占用更多的内存。

为了解决这个问题，Django 为我们提供了两个非常强大且常用的 QuerySet 方法：INLINECODE9b20a91b 和 INLINECODE07f1e989。虽然它们的目的都是为了获取特定的列数据，但返回的数据结构却截然不同。如果你能熟练掌握并区分这两个方法，编写代码的效率和数据处理的灵活性都会大大提升。

在这篇文章中，我们将深入探讨这两种方法的使用场景、内部工作机制以及性能差异。结合 2026 年最新的开发趋势，我们还会讨论如何在 AI 辅助编程（如 Cursor、Windsurf）的背景下，写出更符合现代标准的 Django 代码。无论你是刚接触 Django 的新手，还是希望优化查询性能的老手，这篇文章都将为你提供实用的见解。

1 1. 核心概念速览：从数据结构说起
2 2. 深入解析 values()：结构化数据的首选
3 3. 深入解析 values_list()：极致性能与内存优化
4 4. 2026年视角下的性能优化与生产实践
5 5. 进阶场景：与异步和现代框架的交互
6 6. 常见陷阱与故障排查
7 7. 总结与下一步

1. 核心概念速览：从数据结构说起

首先，让我们从宏观层面快速了解一下这两种方法最本质的区别。理解这一点对于后续的优化至关重要。

values(): 返回一个 QuerySet，其中包含字典。每个字典代表一行数据，键是字段名，值是字段的具体内容。
values_list(): 返回一个 QuerySet，其中包含元组。每个元组代表一行数据，元素是字段的具体值，且严格按照我们指定的顺序排列。

简单来说：INLINECODE034791be 更像是 "带标签" 的数据，方便我们在模板或视图中通过字段名访问；而 INLINECODEd0336ed5 更像是 "纯数据"，结构更紧凑，适合用于批量处理或只需要值的场景。

为了方便演示，我们将定义一个基础的 INLINECODE05cf795d 模型。请在你的 Django 应用的 INLINECODE447189f4 中参考以下代码：

# models.py
from django.db import models

class Book(models.Model):
    """代表一本书籍的模型"""
    title = models.CharField(max_length=255, verbose_name="书名")
    author = models.CharField(max_length=255, verbose_name="作者")
    publication_date = models.DateField(verbose_name="出版日期")
    price = models.DecimalField(max_digits=5, decimal_places=2, verbose_name="价格")

    def __str__(self):
        return self.title

假设数据库中已经有了一些书籍数据，接下来的示例都将基于这个模型展开。

2. 深入解析 values()：结构化数据的首选

values() 方法在我们需要保留字段语义（即字段名）时非常有用。当你把数据传递给 Django 模板或者需要进行 JSON 序列化时，这种方法是首选，因为它自带结构信息。

2.1 基础用法与代码示例

当我们调用 values() 时，Django 会执行 SQL 查询，但不会构建模型实例，而是将结果直接映射为字典。

# 获取所有书籍的标题和作者
# 这里我们只关心 title 和 author，不需要 price 和 publication_date
books_values = Book.objects.values(‘title‘, ‘author‘)

# 查看生成的 SQL (仅在调试时使用)
print(books_values.query)

# 输出结果 (QuerySet 包含字典列表)
#

在这个例子中，你可以看到返回的是一个列表，其中的每个元素都是标准的 Python 字典。我们可以像操作普通字典一样操作它：

for book in books_values:
    # 通过键名直接访问，代码可读性极高
    print(f"书籍: {book[‘title‘]}, 作者: {book[‘author‘]}")

2.2 进阶技巧：使用 annotate 和 values

values() 的强大之处还在于它可以与聚合函数配合使用。例如，我们想统计每个作者写了几本书，或者平均书价是多少。

from django.db.models import Count, Avg

# 按作者分组，并计算书籍数量
author_stats = Book.objects.values(‘author‘).annotate(
    book_count=Count(‘id‘),
    avg_price=Avg(‘price‘)
)

for stat in author_stats:
    print(f"作者: {stat[‘author‘]}, 书籍数量: {stat[‘book_count‘]}, 平均价格: {stat[‘avg_price‘]}")

在这个场景下，INLINECODEfce42bdc 相当于 SQL 中的 INLINECODEded004f8。如果不使用 values()，实现同样的分组逻辑会复杂得多。

3. 深入解析 values_list()：极致性能与内存优化

如果你不需要字段名，只关心纯粹的数据值，那么 values_list() 是更高效的选择。它去除了字典的键名开销，返回的是轻量级的元组。

3.1 基础用法与代码示例

让我们来看看如何使用 values_list() 获取相同的数据，并注意观察输出格式的变化。

# 获取所有书籍的标题和作者，返回元组列表
books_list = Book.objects.values_list(‘title‘, ‘author‘)

# 输出结果 (QuerySet 包含元组列表)
#

注意这里的变化：INLINECODEf7c75fbc 变成了 INLINECODE70638415。在内存中，元组比字典占用更少的空间。

3.2 玩转数据：构建下拉菜单选项

这是 INLINECODE74a68557 最经典的实战场景之一。假设我们需要在 HTML 表单中创建一个“选择书籍”的下拉菜单，通常需要 INLINECODE3991a03b 这样的对列表。直接使用 values_list 可以一步到位。

# 获取 (id, title) 对，非常适合作为 choices 参数
book_choices = Book.objects.values_list(‘id‘, ‘title‘)

# 结果示例：

# 你可以直接将其赋值给 Form 的 choices 字段
# class MyForm(forms.Form):
#     my_book = forms.ChoiceField(choices=book_choices)

3.3 终极武器：flat=True 参数

这是 INLINECODE4782e7aa 最具“杀伤力”的特性。当你只需要获取某一个字段的所有值时，可以使用 INLINECODEded13525。它会将原本包含单元素元组的列表，直接“拍平”成一个包含具体值的列表。

# 获取所有书籍的标题，只想要一个简单的字符串列表
all_titles = Book.objects.values_list(‘title‘, flat=True)

# 输出结果
# 

# 这等价于 Python 中的列表推导式：
# [book.title for book in Book.objects.all()]
# 但数据库层面效率高得多！

注意：INLINECODEcd097ff7 只能在 INLINECODEa152d143 中只指定一个字段时使用。如果你写了 values_list(‘title‘, ‘author‘, flat=True)，Django 会抛出错误。

4. 2026年视角下的性能优化与生产实践

随着我们步入 2026 年，现代 Web 应用的规模和复杂性不断增加，微服务和 Serverless 架构变得愈发普遍。在这种背景下，数据库查询的微小优化都会被无限放大。我们来详细看看如何在生产环境中做出最佳选择。

4.1 内存占用与序列化开销：实时对比

在处理高并发请求（例如 Black Friday 抢购或大规模 API 调用）时，内存的占用直接决定了服务的成本和稳定性。

values() (字典): 字典是哈希表实现的，除了存储数据本身，还需要存储哈希值和指针。对于 10 万条数据，这种额外的开销是巨大的。
INLINECODEfd973dab (元组): 元组是不可变的序列，内存布局紧凑，只存储数据引用。在处理数百万行导出任务时，我们强烈建议使用 INLINECODE8051cc2d 甚至 iterator() 来避免内存溢出（OOM）。

# 生产级示例：大数据量导出
# 场景：我们需要生成一个 CSV 报告，包含 50 万条书籍记录
import csv
from django.http import StreamingHttpResponse

class Echo:
    """模拟文件对象"""
    def write(self, value):
        return value

def export_books_view(request):
    # 推荐：使用 values_list 结合 iterator()
    # values_list 比 values 更节省内存
    # iterator() 告诉 Django 不要缓存查询结果，这对于流式传输至关重要
    queryset = Book.objects.values_list(‘title‘, ‘author‘, ‘price‘).iterator()
    
    pseudo_buffer = Echo()
    writer = csv.writer(pseudo_buffer)
    
    def stream():
        # 写入表头
        yield writer.writerow([‘书名‘, ‘作者‘, ‘价格‘])
        for row in queryset:
            yield writer.writerow(row)
            
    response = StreamingHttpResponse(stream(), content_type="text/csv")
    response[‘Content-Disposition‘] = ‘attachment; filename="books_export.csv"‘
    return response

4.2 AI 辅助开发中的最佳实践 (Vibe Coding)

在 2026 年，我们经常与 AI 结对编程。当你使用 Cursor 或 Copilot 时，明确区分这两者对于 AI 生成正确代码至关重要。

提示词技巧: 如果你直接告诉 AI "获取所有书"，它倾向于生成 Book.objects.all()，这会导致性能隐患。
精准指令: 我们应该训练自己（和 AI）养成这样的习惯："获取所有书籍的 title 列表，用于 React 组件的自动补全下拉框"。AI 会更倾向于生成 Book.objects.values_list(‘title‘, flat=True)，这符合现代开发的 "Vibe Coding" —— 即不仅代码要跑通，还要符合上下文氛围和性能直觉。

5. 进阶场景：与异步和现代框架的交互

现代 Django 开发往往不再局限于服务端渲染 HTML。我们可能在构建 DRF (Django Rest Framework) API，或者使用 Django Ninja (ASGI)。

5.1 在 API 序列化中的抉择

当构建 JSON API 时，values() 看起来很方便，因为它已经是字典结构，似乎可以省去序列化器。但请注意，这是一种 "Code Smell"（代码异味）。

# ❌ 不推荐：直接返回 values 结果，虽然快但失去了数据验证
# 缺乏类型提示，且容易暴露不应暴露的字段（如 password）
@api_view([‘GET‘])
def get_books_raw(request):
    return Response(list(Book.objects.values(‘title‘, ‘author‘))) 

# ✅ 推荐：结合 values_list 和 Pydantic/TypeDict
# 在 2026 年，我们更看重类型安全和数据验证
# 这种写法在 IDE 中有更好的补全支持
from typing import List, TypedDict

class BookDict(TypedDict):
    title: str
    author: str

@api_view([‘GET‘])
def get_books_safe(request):
    # 即使使用 values_list，我们在上层封装了类型定义
    # 这样既享受了查询的高效，又保证了接口的健壮性
    raw_data = Book.objects.values_list(‘title‘, ‘author‘)
    # 简单的映射逻辑（生产环境可由 Pydantic 处理）
    typed_data: List[BookDict] = [{‘title‘: row[0], ‘author‘: row[1]} for row in raw_data]
    return Response(typed_data)

5.2 `named=True`：2026年的新宠？

虽然 Django 核心功能变化不大，但在最新的 Django 版本及社区讨论中，INLINECODEb310dc58 参数（常见于 INLINECODE3e6ae3fa 的第三方扩展或特定 ORM 变体）作为一个折中方案越来越受关注。如果你在使用某些现代 Django 扩展库，记得关注是否支持返回 "命名元组"，它既有元组的性能，又有字典的可读性。

# 模拟概念：获取既有名字又高性能的结构
# books = Book.objects.values_list(‘title‘, ‘author‘, named=True) 
# for book in books:
#     print(book.title) # 像对象一样访问，但内存开销接近元组

6. 常见陷阱与故障排查

即便经验丰富的开发者也会在细节上翻船。让我们看看我们曾在生产环境中遇到的问题及解决方案。

6.1 陷阱：修改数据导致的静默失败

正如前文提到的，INLINECODE349965df 和 INLINECODEed5a7e4b 返回的是字典或元组，它们是静态数据，而不是模型实例。

问题场景: 你可能试图遍历查询集并批量更新状态。

# ❌ 危险代码！不仅不能保存，还会误导你
books = Book.objects.values(‘id‘, ‘status‘).filter(status=‘draft‘)
for book in books:
    if should_publish(book):
        book[‘status‘] = ‘published‘ # 这里只是修改了内存中的字典
        book.save() # ❌ 抛出 AttributeError: ‘dict‘ object has no attribute ‘save‘

解决方案:

# ✅ 正确做法：使用 .update() 方法 (效率最高)
Book.objects.filter(status=‘draft‘).update(status=‘published‘)

# ✅ 或者：如果必须调用业务逻辑方法(如 save 中的信号)，获取实例
# 但要注意性能，分批处理
from django.db.models import Q
batch_size = 500
for start in range(0, Book.objects.filter(status=‘draft‘).count(), batch_size):
    for book in Book.objects.filter(status=‘draft‘)[start:start+batch_size]:
        book.publish() # 假设这是一个自定义方法

6.2 陷阱：N+1 问题的变体

虽然 INLINECODE6af71d3c 通常用来解决 N+1 问题，但如果你在 INLINECODE747a4682 之后又去访问关联对象，依然会触发查询。

# ❌ 低效：即使使用了 values，外键访问依然可能触发查询
# 假设 Book 有一个外键 category
books = Book.objects.values(‘title‘, ‘category_id‘) 
for book in books:
    # 这里如果不小心使用了 book.category.name
    # 由于 values 返回的是字典，没有 category 对象，你会先报错或者不得不重新查询
    print(book[‘category_id‘]) # 只能拿到 ID

如果需要关联字段的数据，必须在 values 参数中显式指定跨表查询：

# ✅ 正确：使用双下划线进行跨表查询
books = Book.objects.values(‘title‘, ‘category__name‘)
# 这样生成的 SQL 是 JOIN 查询，一次性获取所有数据

7. 总结与下一步

在这篇文章中，我们详细探讨了 Django 中 INLINECODE2b7babdb 和 INLINECODE6ff98605 的区别。虽然它们看起来很相似，但在数据结构和应用场景上各有千秋：

values(): 返回字典。适合需要字段名、构建 JSON 或进行分组聚合的场景。
values_list(): 返回元组。适合构建选项列表或需要紧凑数据结构的场景。
INLINECODEc0fd4b26: INLINECODE44fe7e14 的特殊模式，用于获取单列值的列表。
2026 视角: 在云原生和 AI 辅助编程的时代，明确选择这两种方法不仅是性能优化，更是代码可维护性和资源成本的体现。

作为 Django 开发者，理解 ORM 背后的 SQL 转换是进阶的关键。下次当你写查询代码时，不妨停下来想一想：“我真的需要加载整个模型实例吗？还是只需要 values() 就够了？”

希望这篇文章能帮助你写出更高效、更专业的 Django 代码。如果你在项目中遇到了性能瓶颈，不妨检查一下你的查询语句，看看是否可以通过这两个方法进行优化。祝编码愉快！

投稿给我们	如何建站？
vps是什么？	如何安装宝塔？
如何通过博客赚钱？	便宜wordpress托管方案
免费wordpress主题	这些都是免费方案

豆丁博客

Django 开发指南：深入理解 values() 与 values_list() 的差异及最佳实践

1. 核心概念速览：从数据结构说起

2. 深入解析 values()：结构化数据的首选

2.1 基础用法与代码示例

2.2 进阶技巧：使用 annotate 和 values

3. 深入解析 values_list()：极致性能与内存优化

3.1 基础用法与代码示例

3.2 玩转数据：构建下拉菜单选项

3.3 终极武器：flat=True 参数

4. 2026年视角下的性能优化与生产实践

4.1 内存占用与序列化开销：实时对比

4.2 AI 辅助开发中的最佳实践 (Vibe Coding)

5. 进阶场景：与异步和现代框架的交互

5.1 在 API 序列化中的抉择

5.2 `named=True`：2026年的新宠？

6. 常见陷阱与故障排查

6.1 陷阱：修改数据导致的静默失败

6.2 陷阱：N+1 问题的变体

7. 总结与下一步

相关文章美国1G带宽/1T流量高速vps $17.99/年

Django 开发指南：深入理解 values() 与 values_list() 的差异及最佳实践

1. 核心概念速览：从数据结构说起

2. 深入解析 values()：结构化数据的首选

2.1 基础用法与代码示例

2.2 进阶技巧：使用 annotate 和 values

3. 深入解析 values_list()：极致性能与内存优化

3.1 基础用法与代码示例

3.2 玩转数据：构建下拉菜单选项

3.3 终极武器：flat=True 参数

4. 2026年视角下的性能优化与生产实践

4.1 内存占用与序列化开销：实时对比

4.2 AI 辅助开发中的最佳实践 (Vibe Coding)

5. 进阶场景：与异步和现代框架的交互

5.1 在 API 序列化中的抉择

5.2 named=True：2026年的新宠？

6. 常见陷阱与故障排查

6.1 陷阱：修改数据导致的静默失败

6.2 陷阱：N+1 问题的变体

7. 总结与下一步

相关文章美国1G带宽/1T流量高速vps $17.99/年

5.2 `named=True`：2026年的新宠？