Django 开发者调查 2026：在异步、HTMX 与 AI 之间回到“无聊但可靠”

2026-08-28 40 预计阅读时间: 1 分钟
来源: djangoproject.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：9 分钟

Django Software Foundation 与 JetBrains PyCharm 联合发布了第五届 Django Developers Survey。2026 年调查于 5 月至 7 月进行，完整报告包含信息图、开发者引述和按主题划分的章节；Django Chat 也推出了特别节目，围绕 Django 6.1、HTMX、异步、AI、部署、测试和 Python 工具链展开讨论。

这次调查的价值，不只是告诉我们社区正在谈论什么，更在于帮助团队判断：哪些技术适合现在落地，哪些仍然应该保持谨慎。摘要没有列出具体比例，因此本文不虚构排名或百分比，而是把报告覆盖的主题转化为一套可执行的 Django 工程思路。

“无聊”不是停滞，而是可维护性重新成为指标

“Boring is so back”可以理解为一种工程取舍：当业务系统进入长期维护阶段，稳定的请求处理、清晰的模型边界、可重复的测试和可观察的部署，往往比追逐每一个新框架更重要。

对于 Django 团队，这意味着可以继续使用成熟的约定，但不要把“约定优于配置”误解成“不需要设计”。一个值得复盘的清单包括：

  • URL、视图、表单和模型是否各自承担单一职责？
  • 数据库查询是否通过测试或工具持续检查，而不是等线上变慢后再处理？
  • 管理后台、权限和审计是否满足业务要求？
  • 部署过程能否从新环境中重复执行？
  • 升级 Django、Python 和第三方包时，是否有自动化回归测试？

这类工作看起来不新鲜，却直接决定了团队能否安全吸收异步、AI 或新的前端交互方式。

从 HTMX 开始渐进式增强，而不是一次性重写前端

调查相关讨论把 HTMX 列为重点主题之一。对很多 Django 项目来说，HTMX 的吸引力在于：服务器仍然负责渲染 HTML，团队可以为局部交互增加 AJAX 能力，而不必立刻引入完整的前端应用架构。

下面是一个最小的实践示例。假设已经有一个名为 demo 的 Django 项目和一个名为 main 的应用，可以先安装 Django：

python -m venv .venv
source .venv/bin/activate  # Windows 使用 .venv\\Scripts\\activate
python -m pip install Django
python manage.py startapp main

在 main/views.py 中加入一个返回局部 HTML 的视图：

from django.http import HttpResponse
from django.shortcuts import render


def dashboard(request):
    return render(request, "main/dashboard.html")


def refresh_status(request):
    return HttpResponse(
        '<span id="service-status" class="status-ok">服务正常 · 刚刚检查</span>'
    )

在 main/urls.py 中配置路由：

from django.urls import path
from . import views

urlpatterns = [
    path("", views.dashboard, name="dashboard"),
    path("status/", views.refresh_status, name="refresh_status"),
]

在项目的根 URL 配置中引入它：

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path("admin/", admin.site.urls),
    path("", include("main.urls")),
]

创建 main/templates/main/dashboard.html：

<!doctype html>
<html lang="zh-CN">
  <head>
    <meta charset="utf-8">
    <title>Django Dashboard</title>
    <script src="https://unpkg.com/htmx.org@2.0.4"></script>
  </head>
  <body>
    <h1>系统状态</h1>
    <div id="service-status">尚未检查</div>
    <button
      hx-get="/status/"
      hx-target="#service-status"
      hx-swap="outerHTML">
      刷新状态
    </button>
  </body>
</html>

运行开发服务器并访问 http://127.0.0.1:8000/：

python manage.py migrate
python manage.py runserver

这个例子适合内部后台、列表筛选和状态面板等场景。它不是说 HTMX 总能替代前端框架；当页面需要复杂的客户端状态、离线能力或大量并行交互时，独立前端仍可能更合适。关键是让交互复杂度与业务复杂度匹配。

异步和 AI：先解决边界问题，再谈技术升级

Django Chat 的特别节目还涉及异步和 AI。落地时，团队最好分别评估这两类能力，不要把它们混成一个“现代化改造”项目。

异步视图适合等待外部异步服务、流式响应或大量 I/O 的场景，但它不会自动让数据库查询变快。同步 ORM 调用、阻塞式 SDK 和文件操作，仍然可能阻塞事件循环。一个可运行的异步视图示例如下：

import asyncio
from django.http import JsonResponse


async def readiness(request):
    # 示例：模拟一次异步外部检查。
    # 真实项目中应替换为支持 async 的 HTTP 客户端调用。
    await asyncio.sleep(0.05)
    return JsonResponse({"status": "ready"})

如果必须调用同步库，应明确隔离同步边界，并为超时、重试和取消行为编写测试。不要仅仅因为写了 async def，就宣称整个请求链路已经异步化。

AI 集成也应遵循同样的边界意识。可以先从低风险、可回退的功能开始，例如后台内容摘要、客服草稿或内部搜索辅助；对于权限判断、金额计算、数据删除等关键流程，仍然应由确定性的业务代码控制。模型输出要经过验证、审计和限流，提示词不能替代授权逻辑。

把调查主题转成团队行动计划

可以按下面的顺序使用这份调查：

  1. 先读完整报告的章节和图表：确认哪些结论适用于自己的团队，而不是只根据标题做判断。
  2. 选择一个低风险试点：例如用 HTMX 改造一个后台局部刷新页面，或为一条外部 I/O 链路增加异步实验。
  3. 把升级放入测试矩阵：同时覆盖 Python、Django、数据库和关键第三方包，避免只在开发机上验证。
  4. 为部署和回滚补齐自动化：新版本应能构建、迁移、健康检查，并在失败时回到上一个可用版本。
  5. 记录技术决策：写清楚为什么选择服务器渲染、异步、AI 或某个工具，以及什么条件下需要重新评估。

真正值得带回项目的，不是“必须采用某项技术”，而是更可靠的判断流程：先确认问题，再选择最小方案；先建立测试和观测，再扩大使用范围。对 Django 开发者而言，这种可预测、可维护的工程方式，正是“无聊但可靠”重新变得重要的原因。

# AI # Django # Go # Python # 前端 # 后端 # 工程效能

相关推荐