当前位置：首页 > 问答 > 正文

用Django模板直接操作数据库数据到底怎么搞，有啥注意点和坑

符海莹
问答
2026-01-18 08:25:15
6

用Django模板直接操作数据库数据,这个说法其实有点模糊，但核心意思是：如何在模板（就是那些.html文件）里把数据库里的东西拿出来、展示出来，甚至进行一些简单的判断和操作，首先必须明确一个核心原则：Django的设计哲学是“模板中不应该包含复杂的逻辑”，尤其是直接执行数据库查询。 你应该在视图函数（views.py）里把数据查好、处理好，然后像打包礼物一样传给模板，模板只负责拆开包装、展示内容。

正确的搞法：视图函数干活，模板只负责展示

这才是标准操作,比如你有一个模型叫 Article（文章），你想在首页列出所有文章标题。

在views.py里：你写一个视图函数，在这里进行数据库查询。

from django.shortcuts import render
from .models import Article  # 从你的模型文件导入Article模型
def article_list(request):
    # 这一行就是在操作数据库，获取所有文章对象
    articles = Article.objects.all()
    # 把查询到的数据放进一个字典里，传给模板
    context = {
        'article_list': articles
    }
    return render(request, 'blog/article_list.html', context)

关键点：所有复杂的查询，比如过滤（filter）、排序（order_by），都在这里完成。articles 变量现在就是一个包含所有文章数据的查询集（QuerySet），你可以把它理解成一个装满数据的列表。

在urls.py里：配置一下网址，让用户访问某个网址（/articles/）时，能触发上面这个 article_list 函数。
在模板article_list.html里：这时候你就可以“直接”使用数据库里的数据了。
```
<h1>文章列表</h1>
<ul>
    {% for article in article_list %}
    <li>{{ article.title }} - 发布于：{{ article.pub_date }}</li>
    {% endfor %}
</ul>
```
这里,{% for ... %} 是模板标签，用来循环；是模板变量，用来显示内容，你看，模板里并没有出现 Article.objects.all() 这样的数据库查询语句，它只是在处理视图函数传过来的 article_list 这个“现成的”数据。

所谓的“直接操作”和它的巨坑

虽然不推荐,但Django模板确实有能力做到一些“类似”直接查询的操作，这往往是坑的来源。

惰性求值与N+1查询问题 这是最常见、最影响性能的坑，Django的查询集（QuerySet）是“惰性”的，意思是只有当你真正用到数据时，它才会去数据库查询。假设文章模型有一个外键指向用户模型 User（作者），在视图里，我们只查询了文章：
```
articles = Article.objects.all()
```
在模板里,我们循环展示文章标题和作者名：
```
{% for article in article_list %}
    <p>{{ article.title }} by {{ article.author.username }}</p>
{% endfor %}
```
坑来了：循环第一篇文章时，Django去数据库取第一篇文章的数据，然后为了显示 article.author.username，它又发起一次查询去取这个作者的信息，循环第二篇文章时，同样的事情再来一遍，如果你有100篇文章，就会产生1次（取文章列表）+ 100次（逐条取作者信息）= 101次数据库查询！这就是恐怖的N+1查询问题。 解决方法：在视图函数查询时，使用 select_related（用于一对一、多对一关系）或 prefetch_related（用于多对多关系）进行优化。
```
articles = Article.objects.all().select_related('author')
```
这样,Django会在第一次查询文章时，通过SQL的JOIN语句一次性把作者信息也取出来，模板里再循环就只会有1次数据库查询。
在模板中执行“类似”查询的方法（极度不推荐） 你可能会看到一种写法，利用模型的反向关系，在模板里看起来像是在查询。在用户详情页，视图只传了一个用户对象 user，模板里你想显示这个用户写的所有文章：
```
<h1>{{ user.username }}的文章</h1>
{% for article in user.article_set.all %}
    <p>{{ article.title }}</p>
{% endfor %}
```
user.article_set.all 这里的 .all 看起来像是在模板里执行了查询，它确实会触发一次新的数据库查询，这本质上就是上面N+1问题的一种形式，如果其他地方也用到了类似结构，性能问题会叠加。正确的做法依然是：在视图函数里，通过 prefetch_related 提前把关联数据取好。
```
user = User.objects.prefetch_related('article_set').get(id=user_id)
```
自定义模板标签/过滤器里的查询 当你需要更复杂的逻辑时，可能会写自定义模板标签，在这些自定义标签的函数里，你是可以执行数据库查询的，但这需要非常小心，同样要避免N+1问题，并且要考虑到查询结果的缓存，除非万不得已，尽量把数据准备的工作放在视图层。

总结与核心注意点

坚守MVC/MTV原则：视图（Controller/View）是大脑，负责逻辑和数据；模板（Template）是脸面，负责展示，不要让脸去干大脑的活儿。
性能瓶颈在数据库：模板渲染本身很快，慢的是数据库查询，任何在模板中可能触发额外SQL查询的地方都是重点优化对象。
善用Django调试工具栏：安装 django-debug-toolbar 这个神器，它能清晰地展示出渲染一个页面总共执行了多少次SQL查询、每次查询耗时多久，是发现N+1等问题的最佳工具。
复杂度判断：如果只是显示一个对象的某个属性，或者遍历一个预先取好的列表，这在模板里是完全可以的，但如果需要根据条件进行过滤、排序、聚合等操作，请务必移步到视图函数中完成。

Django模板的“直接操作”能力是有限的，而且是故意被设计成有限的，它的强大在于数据展示和简单逻辑控制，而不是数据获取，把数据和逻辑清晰地分离，不仅是Django的最佳实践，也能让你的代码更易维护、性能更好，模板越“笨”，你的应用通常就越健壮。