去年年底我给自己立了一个看起来有点“返工”的目标把 Django 官网的 Poll 教程从头到尾完完整整敲一遍。为什么专门干这件事因为我虽然用 Django 写过不少接口但大部分知识来自同事的代码和零散的博客很多机制都是“能用就行”框架的底层设计到底是怎么回事心里一直没底。这次把官方教程老老实实走完收获远比我预期的大所以想把这次的实战结果完整复盘一遍。这篇文章就是那次实战之后的经验沉淀。我会按官网教程的推进顺序把每一步里容易绕弯的地方、值得反复读的地方、以及教程里没有讲但真实项目一定会遇到的衍生点全部串起来。无论你是刚接触 Django 的新手还是写过几个 demo 但没系统学过的人这篇内容应该都能让你少走几步弯路。1. 教程走完后我对Django官网教程的整体定位1.1 官网教程到底教了什么官网教程的全称是“编写你的第一个 Django 应用”核心成果是一个投票应用。整个流程分好几个部分从创建项目、创建应用到定义Question和Choice两个模型再到通过 admin 后台维护数据接着写视图、配 URL、做模板然后处理表单提交、把函数视图升级成通用视图再给代码写测试最后处理静态文件和自定义 admin 界面。每一步都跟着敲下来你手里会多一个能投票、能看结果、带后台管理的完整小应用。如果只看最终成果它确实不起眼但如果看过程你会发现教程几乎是手把手演示了一个 Django 项目的完整生命周期。这正是我最推荐新手完整走一遍的原因官网教程不教炫技教的是标准工作流。从数据模型设计到请求处理的每个环节它都明确告诉你“一个正常项目应该长这样”而不是让你东拼西凑地堆积代码。1.2 谁能从这套教程里真正受益我的判断是教程最适合两类人群。第一类是刚学完 Python 基础、对 Web 框架只有模糊概念的人教程能让你在两三天内建立起“MVT ORM 模板”的整体画面。第二类是像我这样有项目经验但基础不稳的人它能帮你把之前那些“抄作业抄来”的代码重新校准一遍搞清楚为什么前辈们要那样写。只有一种人群我不太推荐硬啃连 Python 语法都还没理顺的初学者。教程里不会解释装饰器、类继承、对象关系映射这些基础概念如果一边查语法一边跟教程容易卡在细节里出不来。建议先把 Python 基础过一遍再来怼这个教程效率会高很多。我自己带过几个新人凡是顺序反了的最后都回来补 Python 基础反而更慢。1.3 教程真正的价值不是那个投票应用走完之后我最大的感受是官方教程的每个代码块都在传达 Django 团队的“推荐做法”而不是单纯给一个能跑的东西。比如它坚持让你先定义好模型再做迁移坚持用 URL 命名空间而不是写死路径坚持用get_object_or_404而不是自己 try/except。严格来说这些都不是功能必需但却是项目后期维护友好度的分水岭。所以如果你想从教程里提炼一点方法论那就是写 Django 项目的顺序应该始终围绕“数据模型 → 数据访问 → URL 路由 → 视图逻辑 → 模板呈现”这条链路去展开。不管项目多大多小这个骨架都不应该乱。后来我自己做任何新功能时都会先问一句“数据长什么样”而不是“页面长什么样”这一个习惯的改变就是官网教程给我的最大收益。2. 从零搭建项目最容易绕弯的几个环节2.1 环境准备版本选择与虚拟环境官网教程从创建虚拟环境开始。这一点我强烈建议不要跳过也不要图省事直接pip install django装到全局环境里。用python -m venv或者你习惯的虚拟环境工具把项目依赖和系统环境隔离这是后面所有工作的地基。我见过太多人因为全局环境里的 Django 版本和项目不一致排查一整天最后发现是环境问题。版本选择上教程对应的是当前稳定版现在主流教程已经跟着 Django 4.x 甚至 5.x 更新了。我的建议是直接装最新的稳定版但不要为了猎奇去装 alpha 或者 beta 版本。另外项目根目录下一定记得维护一份requirements.txt把自己安装的依赖和版本号固定下来。这一步教程不会刻意强调但真实项目里版本漂移引发的“在我电脑上能跑”问题十个里面有八个是因为没做依赖锁定。2.2 startproject 和 startapp 之间到底隔离了什么教程里这两个命令会让新手产生一个困惑为什么先建了 mysite 又建了一个 polls它们之间是什么关系我的理解是startproject创建的是“项目”负责配置、路由分发、部署入口可以把它想象成一个房子的总水管和配电箱startapp创建的是“应用”负责具体的业务模块相当于客厅、厨房这些功能区。一个项目里可以挂多个应用一个应用也可以被多个项目复用这才是 Django 推荐的组织方式。很多新手把所有代码往一个应用里塞后患无穷。mysite 目录下的settings.py、urls.py、manage.py分别是总配置、总路由和命令行入口。刚开始不用死记每个文件的作用但至少要理解manage.py是你和项目交互的主要通道后面所有操作几乎都从它出发。比如跑开发服务器、执行迁移、创建超级用户都是python manage.py xxx的格式。把它当成项目的“遥控器”会好记很多。2.3 第一份URL配置path与include官网教程在给 polls 应用配置第一条 URL 时用的方式是在项目urls.py里include应用自己的urls.py。很多新手会想为什么不直接在项目urls.py里写path(, views.index)理由其实很朴素把应用内部的路由放在应用自己的urls.py里项目只负责挂载前缀。这样 polls 这个应用可以整体搬到另一个项目里只要前缀一改就行如果所有路由都堆在项目urls.py里应用就失去了可复用性。你自己写项目的时候如果发现有多个应用但路由全在项目级文件里那基本可以判断组织方式出问题了。path函数里还有一个非常关键的东西转换器。教程里path(int:question_id/, views.detail)中的int:question_id会把 URL 中这个位置捕获成一个整数参数传给视图函数。这个看起来简单的语法实际上把类型转换和参数校验一起做了比自己去字符串截取要优雅得多。等你想做一个按 slug 显示的博客文章页时换成slug:slug就能达到同样效果。3. 模型与数据库官网教程里最值得反复咀嚼的部分3.1 为什么先写模型如果你之前习惯先画页面再写接口教程会立刻给你一个反向刺激先定义Question和Choice两个模型类然后立刻做迁移把数据表建好再去碰视图和模板。这个顺序背后是 Django 的核心思想数据是一切业务的起点。Question里有question_text和pub_dateChoice里有choice_text和votes并且用ForeignKey指向Question。这里我建议你仔细看一下 Choice 里的外键定义方式它会自动把一对多关系翻译成choice.question和question.choice_set其中choice_set是 Django 靠命名约定生成的子对象管理属性。理解了_set这个约定后面处理一对多、多对多关系都不会再慌乱。模型字段的类型也需要用心感受一下CharField、DateTimeField、IntegerField不只是简单的“数据类型声明”它们同时还决定了表单校验、admin 输入控件和数据库字段类型。比如DateTimeField在 admin 里会自动渲染日期控件而IntegerField会拒绝非数字输入。一个模型写对了后面很多层的代码都能省下来。3.2 迁移机制makemigrations 和 migrate 到底在做什么第一次跑python manage.py makemigrations polls之后教程会让你看看 migrations 目录下多了一个文件还展示了sqlmigrate能看到对应的 SQL。很多新手以为迁移就是把数据库建好其实迁移的精髓是把模型变化变成一份可追踪、可回滚的变更日志。实际项目里迁移文件的顺序是神圣的不要手工去数据库里改表结构也不要图省事删除迁移文件再重新生成尤其是项目上了多环境以后。你每一次字段变更都会在迁移历史里留下记录队友拉代码后只需要migrate就能把库表同步到一致状态。直白一点说迁移机制就是团队协作时保证数据库结构不改乱的保险丝。我见过太多人为了“省事”手工加字段然后所有人的环境都开始报 “no such column”最后只能靠对表结构硬核对。教程从第4部分开始还引入了字段约束的例子比如给Choice加UNIQUE约束防止同一个问题里出现重复选项文本。这种约束写在模型层比在视图里做 if 判断要可靠得多。数据库层面的边界越严应用层的代码就越简单。3.3 ORM查询与删除CRUD基本功教程在 shell 环节演示了创建、查询、过滤、删除这一整套 ORM 操作。这里我提两个常被忽略的知识点。第一Question.objects.filter(pub_date__yearcurrent_year)里双下划线__是 ORM 查字段、走关系的统一语法。改成pub_date__gte...就是大于等于改成choice__choice_text__startswithA就能从 Question 反向查询关联 Choice 的字段。这套语法熟悉之后写查询基本不需要记 SQL。我面试新人时只要看他能不能熟练说出几个__查询条件基本就能判断他有没有认真写过 Django 项目。第二删除操作。question.choice_set.all().delete()或者question.delete()的级联行为对应数据库中外键的 ON DELETE CASCADE。实操的时候要格外小心删除一个Question关联的Choice会被一并清掉Django 执行后还会提示你删除了多少条对象。这个行为在生产环境对数据的杀伤力很大所以批量删除之前一定要确认关联关系必要时用Collect外键的on_deletemodels.PROTECT来阻止误删。教程投票功能的代码里用到了F(votes)这是 Django 提供的原子递增写法读出来再加一再写回去在高并发下也不会丢更新。如果自己写choice.votes 1再 save()在并发请求时会有竞态问题。这个知识点在教程里很容易被当成小技巧跳过去但它其实是数据库并发安全的一个经典示例。凡是涉及“计数”“余额”“库存”这类字段都应该优先考虑用F()表达式。3.4 一个不得不说的坑时区教程里所有时间相关字段都用timezone.now()而不是datetime.now()。区别在于Django 开启USE_TZ True后所有时间都按 UTC 存储展示时才按本地时区转换。如果你在代码里直接塞了一个 naive 的本地时间轻则时间偏移几个钟头重则直接报错。这是教程里一笔带过但实际项目必踩的问题。建议从一开始就养成习惯所有模型里新增时间字段要么用auto_now_addTrue要么显式调用timezone.now()不要依赖datetime.now()。同时把TIME_ZONE设置成你业务面向的区域比如国内项目常设成Asia/Shanghai而USE_TZ保持True。这样存库和展示两边都不别扭。4. 视图、模板与URL把数据变成页面的完整链路4.1 函数视图到通用视图这一步为什么关键官网教程先让你手写index、detail、results三个函数视图代码量不长但模式高度重复查数据、传给模板、返回render。到了后面部分教程把这几个视图换成了ListView和DetailView通用视图代码一下子短了一大截。我起初觉得通用视图不好理解因为它的魔法成分太多类继承、类属性、默认命名约定一不小心就不知道它在渲染什么。后来我理解了通用视图的本质是把“单对象页面”“列表页”这类高频模板抽象出来你用特定名字的属性和约定它替你完成查询和渲染。教程里用了model Question和template_name polls/detail.html去接管默认行为这个思路值得延伸到自己的项目里凡是重复三轮以上的视图就该考虑抽通用视图或者 mixin不要一直复制粘贴。当然函数视图并不是要被抛弃。初期用函数视图把业务逻辑完整写一遍再对照通用视图来重构是最能理解“抽象”的方式。直接一上来就背通用视图的写法很容易变成“会套模板但不理解”遇到需要自定义查询集或上下文时就懵了。4.2 模板渲染与模板继承模板部分除了循环、变量、过滤器这些基础语法最该掌握的是模板继承。教程用polls/base.html搭了一个总架子子模板通过{% extends polls/base.html %}和{% block content %}填充内容。这和 CSS 里的抽公共样式是同一个思路公共的导航、页脚、头部只写一次。等你做有十几个页面的项目时没有模板继承的日子根本没法过。我在实操中养成的习惯是模板的相对路径前缀一定要带应用名比如polls/index.html否则两个应用里假如都有index.htmlDjango 的模板查找机制很可能让你踩到“渲染成别人的页面”的坑。这是教程不会强调但项目一多马上就会遇到的问题。另外模板里尽量只做展示逻辑复杂的业务计算应该放在视图或模型方法里否则模板越来越重维护成本直线上升。模板调试还有一个很实用的点Django 的报错页面会直接告诉你模板加载失败是在哪个目录找不到文件并且列出所有搜索过的路径。新手看到那一屏幕报错不要慌直接看最后的“Template-loader postmortem”那里基本已经把答案告诉你了。4.3 URL命名与reverse一次改动省下大量返工教程里给每个视图都起了 URL 名字并且通过app_name polls加上了命名空间。于是模板里就能写{% url polls:detail question.id %}而不是写死/polls/1/。这个做法的好处等你某天改了 URL 结构时才会真正体会到只要 URLconf 里name不变模板和视图里所有引用都不需要改动。反过来如果你把路径写死在模板里下次路径一调整就是全局搜索替换。配合视图里的reverse(polls:results, args(question.id,))URL 变成了一个可以反向解析的标识而不是一串脆弱的字符串。这对我来说是教程里最有“工程味”的提醒之一。再加上{% url %}在模板渲染时如果对应的 URL 名称写错会直接报NoReverseMatch异常这其实是个很好的保护机制它让 URL 错误在开发期就暴露而不是等到线上用户点击才发现链接 404。5. 表单、静态文件与Admin教程中暗藏的生产力工具5.1 处理POST请求的正确姿势投票功能要处理form methodpost教程的vote视图演示了完整的处理步骤从request.POST里取参数、查找对象、累加票数、保存、最后重定向。这里一定要留意两个细节。第一模板里必须带{% csrf_token %}否则 Django 会拦下 POST 请求。CSRF 防护是 Django 默认开启的它通过生成一次性 token 来防止跨站请求伪造新手经常因为这行缺失导致表单提交 403半天找不到原因。第二教程在处理“投票项不存在”时用了 try/except但更地道的写法其实是get_object_or_404它能帮你省掉异常分支语义也更清晰。视图里代码的分支数量是一个信号分支太多说明逻辑可以往下层或多个方法拆分。还有一个非常优秀的习惯是“POST 成功后必须重定向”。教程在投票成功后return redirect(polls:results, ...)避免用户刷新页面时重复提交表单。这个模式叫 Post/Redirect/Get是 Web 开发的经典规范。别看它简单很多新手包括曾经的我都会偷懒直接render一个结果页结果用户一刷新就重复投票。后来养成了“写 POST 视图先写 redirect”的习惯再没出过这种问题。5.2 静态文件为什么不能用全服务器路径教程部分引入了{% load static %}和{% static polls/style.css %}。它的好处在于开发环境的静态文件路径和生产环境经过collectstatic归拢后的路径可以完全不同模板里只有一个逻辑引用。很多新手会图省事直接在模板里/static/polls/style.css写死本地能跑一部署就开始报样式 404。Django 官方推荐的方式几乎就是为部署留出后路的建议从一开始就遵守。如果你还不太熟悉可以先把STATICFILES_DIRS指到项目根目录下的 static 文件夹把公共的 JS、CSS、图片统一丢进去管理。静态文件这块还有一个隐藏知识点开发时 Django 用runserver帮你托管静态文件但生产环境通常需要 Nginx 这类服务来托管并且用manage.py collectstatic把所有应用里的静态文件统一收集到一起。教程不会带你走完部署全流程但静态文件的引用方式就是在为这一步做准备。5.3 Admin后台教程里最被低估的模块到了自定义 admin 的部分我几乎是第一次意识到 Django 的 admin 不只是“自带的简易后台”而是一个可以快速搭建员工管理后台的生产力工具。教程演示了list_display、list_filter、search_fields、fieldsets以及StackedInline内联子表。我记忆里最深刻的是仅仅用声明式的列表和字典就能在几分钟内把后台从“白板”变成一个带筛选、搜索、分组编辑的界面。这里想多句嘴真实项目里admin 不是只能给 Django 超级管理员用。很多企业内部后台、运营系统、内容管理系统完全可以直接用 Django admin 加上权限控制来实现省掉一大块重复的前端开发。教程这一段如果你看懂并扩展后续会发现它比很多现成的“admin 脚手架”更灵活。尤其是结合热词里有人提到的unfold这类 UI 主题配好后整体观感也很现代完全没有早期那种“极客后台”的感觉。你还可以在 admin 里重写save_model方法在保存时自动填充操作人、更新时间或者对某些字段做额外的校验。这些扩展点教程只是开了个头但都值得自己动手试一遍。6. 做完官网教程不等于会做项目还差这几门实战课6.1 认证与登录官网教程缺席的第一课官网 Poll 教程从头到尾没有做登录注册。但任何一个真实项目第一件事就是谁在访问、有没有权限访问。Django 自带的django.contrib.auth提供了一套完整的基于 session 的认证体系包括 User 模型、登录/注销视图、login_required装饰器以及permission_required之类的权限判断。真实业务往往还要做“业务主体和账号绑定”比如一个投票应用应该允许“一个用户对同一个问题只投一次”。教程里没有这种需求但你可以立刻把它作为第一个扩展练习给 Choice 增加一个voters models.ManyToManyField(settings.AUTH_USER_MODEL)再在视图里判断当前用户是否已经投过票。做完这个练习你对认证和业务数据关联的理解会比看十篇博客都深。还有一个容易被忽略的坑Django 的默认 User 模型虽然能用但如果你预见到以后想给用户加手机号、昵称等自定义字段最好在项目一开始就通过AUTH_USER_MODEL换成自定义用户模型。这个决定越晚做越痛苦因为中途换用户模型需要非常复杂的迁移操作。6.2 cookie 与 token状态管理的两种思路教程告诉你 Django 如何在服务端存 session、客户端只拿一个 sessionid cookie。但现在的项目里前后端分离越来越多于是 JWT 之类的 token 方案也十分常见。我的建议是搞清楚二者各自的适用场景服务端渲染的传统页面用 session cookie 最简单Django 开箱即用如果前端是 SPA客户端和小程序共用接口那用基于 token 的认证更合适。实现上可以用djangorestframework-simplejwt把登录接口换成签发 access token 的逻辑。token 和 cookie 也不是二选一token 可以放在 HttpOnly cookie 里下发兼顾安全和跨端能力。cookie 的坑主要在属性上HttpOnly防止脚本读取、SameSite缓解 CSRF、Secure只允许 HTTPS。我在实际接口联调时经常发现前端明明能拿到 token但请求就是不带上排查到最后往往是 cookie 的SameSite属性没配好或者前端withCredentials没开。这些细节官网教程完全不会讲但联调时一定会撞上。6.3 权限模型为什么RBAC比“加个用户字段”更优网站后台永远绕不开权限设计。教程没讲但很多人搜 “django rabc”估计是在做后台权限。这里的建议核心是不要一上来就自己设计一套user.is_superuser加各种is_xxx_manager布尔字段的系统。RBAC基于角色的访问控制才是主流解法用户关联角色角色关联权限权限落在资源操作上。Django 自带的 Group 和 Permission 就是一套现成的 RBAC。你可以在 admin 里建“运营组”“编辑组”然后给每个组勾选对某个模型的 add/change/delete 权限视图里用user.has_perm做细粒度校验。等你的业务真的需要区分角色、职责、操作域时直接用这套机制会比自己维护一堆布尔字段干净得多。我在一个内容管理系统里吃过自定义权限模型的亏第一版需求只有一个“总编辑”和“普通编辑”我就加了个布尔字段三个月后要加“审核人”“作者”角色才意识到整套布尔字段已经覆盖不住了。如果一开始就上 Django 内置的Permission模型后面扩展会轻松很多。6.4 数据推送从轮询到WebSocket另一个常和 Django 关联搜索的场景是后台一有数据变化前端要马上收到。这里如果一个页面只是定时去拉GET /api/status就是轮询简单但浪费请求更好的体验是 WebSocket 这种长连接后端能主动把消息推给前端。Python 生态里做这件事的路线通常是给 Django 套上 ASGI再用 Django Channels 管理 WebSocket 连接业务完成后往 channel layer 里发送消息前端就能收到推送并更新页面。如果你只是想让“有后台数据时前端自动更新”也有一个过渡方案用 Server-Sent Events 单向推送。选择哪个取决于更新频率和是否需要前端回传消息通道。需要提醒的是WebSocket 的调试比普通 HTTP 麻烦得多。建议先把 HTTP 接口和业务逻辑全部调通再加推送层否则两边一起排查会很痛苦。我自己第一次做实时通知时业务逻辑没问题消息也发出去了但前端一直收不到最后发现是 ASGI 和 Channels 中间件顺序的问题。6.5 管理后台颜值不够试试第三方UI主题教程自带的 admin 界面偏“极客风”但实际做内部系统时大家总是希望后台好看一点。现在社区有不少基于 Django admin 的现代 UI 主题比如 unfold、django-admin-interface 这些装上之后配色、布局、暗色模式都有明显改善。我的观点是优先改样式不要轻易推翻 admin 重写前端。Django admin 的价值在于它的权限、表单验证、日志记录是现成的你只需要通过自定义 admin 类把展示和操作调整得贴合业务再配合第三方主题提升颜值投入产出比很高。我见过有人嫌 admin 丑直接做了一个独立 Vue 后台来对接同一套模型最后权限、日志、表单校验全都要重新造维护成本成倍增长。6.6 部署跑在开发服务器上不算完成教程全程用python manage.py runserver但它不能直接上生产。真实部署至少要考虑三件事静态文件收集collectstatic、应用服务器Gunicorn/uWSGI和反向代理Nginx再加上数据库迁移和日志。部署链路任何一个环节不熟项目就永远是“我能跑别人跑不了”。比较稳的学习路径是先在云主机上手动搞一遍看着 Nginx 转发请求给 Gunicorn、Gunicorn 加载你的 Django 应用并和数据库建立连接整个过程虽然琐碎但对整个 Web 请求生命周期会有一个不可替代的体感。如果一开始就图省事上 Docker Compose 一把梭反而可能漏掉很多概念。另外runserver在 DEBUGFalse 的情况下是不会托管静态文件的也不会对小错误做容错。很多人本地一切正常一关 DEBUG 就白屏基本都是因为静态文件没有collectstatic或者 ALLOWED_HOSTS 没配置好。这些问题部署一次就能记住但看教程永远记不住。7. 我的实战结果复盘与经验清单7.1 用什么样的节奏学完最舒服我个人的经验是官网教程拆成三个晚上比较合适第一晚做环境和模型第二晚做视图模板和表单第三晚做测试、静态文件和 admin。想一天啃完也可以但容易漏细节后面如果去扩展项目会发现很多概念是夹生的。学习过程中最好准备一个自己的扩展点比如把教程的投票改成“用筛选项过滤的不同排行榜”“把结果导出 CSV”等等。教程给出的是标准答案你自己改出来的部分才是真正内化的知识。我不建议直接复制粘贴代码哪怕先照着敲一遍再删掉重写一遍效果都会完全不同。7.2 我在教程外踩过的坑这个部分我想列几个复现概率极高的坑都是我实际遇到过的事。第一个坑是忘记迁移。改完模型不执行makemigrations结果在 admin 里找不到新字段或者在视图查询时报 “no such column”。解决办法是形成肌肉记忆模型一改立刻迁移两步走。第二个坑是模板路径。前面提过两个应用都叫index.html时模板查找很容易张冠李戴解决方案就是模板路径带应用名前缀并且命名得具备可读性。第三个坑是数据库驱动的选择。教程默认用 SQLite本地非常爽但部署后第一件事往往就是换 PostgreSQL。从第一天就在settings.py里用环境变量读取数据库配置会让你后面切换数据库时不用改代码。举个例子直接写死sqlite3数据库路径的配置换 PostgreSQL 时要动好几处用环境变量读取的话本地写.env服务器写系统环境变量代码完全不动。第四个坑是自定义用户模型的时机。如果你预感到以后要扩展用户字段就在第一次migrate之前把AUTH_USER_MODEL配好。这个决定最晚不要拖到项目上线后否则数据迁移会让你欲哭无泪。7.3 我沉淀下来的学习法既然这次是“实战结果复盘”我想把自己沉淀下来的学习和排查方法也说透。一个是“看报错但更要看文档和源码”。Django 的报错页面本身信息量很大调用栈、模板渲染位置、上下文变量几乎都在里面。有些问题搜索半天不如直接点开报错页面里的 Debug 信息。还有当某个 API 行为不符合预期时直接按住 Ctrl 点进源码看注释往往比看二手博客更准确因为文档偶尔滞后但源码永远是代码执行的真实依据。另一个是“每个官方链接我都顺手打开过”。Django 文档的索引和 API 参考写得很有条理你写一次QuerySet的 filter顺手把相关文档里的exclude、annotate、select_related都扫一眼比专门找一篇文章学效率更高。很多高级查询功能我就是这样在学教程的过程中顺手积累下来的后面做报表接口时用annotate直接省掉大量 Python 层循环。7.4 教程完成后怎么往前走最后我想聊聊“学完官网教程之后该做什么”。我的建议是立刻找一个自己感兴趣的领域做一个 2 到 3 张数据表的小项目例如图书管理、记账本、团队日程。做的时候延续教程里学的原则模型先行、URL 命名、表单用 POST、后台顺手配好把标准流程再走一遍。当你发现自己做的项目已经开始遇到教程没有覆盖的问题比如认证方式不匹配、数据访问频繁需要缓存、后台需要权限细分恭喜你那才是真正进入 Django 实战的起点。教程给的是地图走出来的路才是你自己的。后面无论你是继续深入研究 DRF 做接口还是转去学 Channels 做实时功能官方教程打下的这条标准工作流都会一直帮你兜底。 
长河君 · 2026/10/13 13:13:21 · 阅读 1.2k Django官网教程实战复盘：从投票应用看框架核心与避坑指南
去年年底我给自己立了一个看起来有点“返工”的目标把 Django 官网的 Poll 教程从头到尾完完整整敲一遍。为什么专门干这件事因为我虽然用 Django 写过不少接口但大部分知识来自同事的代码和零散的博客很多机制都是“能用就行”框架的底层设计到底是怎么回事心里一直没底。这次把官方教程老老实实走完收获远比我预期的大所以想把这次的实战结果完整复盘一遍。这篇文章就是那次实战之后的经验沉淀。我会按官网教程的推进顺序把每一步里容易绕弯的地方、值得反复读的地方、以及教程里没有讲但真实项目一定会遇到的衍生点全部串起来。无论你是刚接触 Django 的新手还是写过几个 demo 但没系统学过的人这篇内容应该都能让你少走几步弯路。1. 教程走完后我对Django官网教程的整体定位1.1 官网教程到底教了什么官网教程的全称是“编写你的第一个 Django 应用”核心成果是一个投票应用。整个流程分好几个部分从创建项目、创建应用到定义Question和Choice两个模型再到通过 admin 后台维护数据接着写视图、配 URL、做模板然后处理表单提交、把函数视图升级成通用视图再给代码写测试最后处理静态文件和自定义 admin 界面。每一步都跟着敲下来你手里会多一个能投票、能看结果、带后台管理的完整小应用。如果只看最终成果它确实不起眼但如果看过程你会发现教程几乎是手把手演示了一个 Django 项目的完整生命周期。这正是我最推荐新手完整走一遍的原因官网教程不教炫技教的是标准工作流。从数据模型设计到请求处理的每个环节它都明确告诉你“一个正常项目应该长这样”而不是让你东拼西凑地堆积代码。1.2 谁能从这套教程里真正受益我的判断是教程最适合两类人群。第一类是刚学完 Python 基础、对 Web 框架只有模糊概念的人教程能让你在两三天内建立起“MVT ORM 模板”的整体画面。第二类是像我这样有项目经验但基础不稳的人它能帮你把之前那些“抄作业抄来”的代码重新校准一遍搞清楚为什么前辈们要那样写。只有一种人群我不太推荐硬啃连 Python 语法都还没理顺的初学者。教程里不会解释装饰器、类继承、对象关系映射这些基础概念如果一边查语法一边跟教程容易卡在细节里出不来。建议先把 Python 基础过一遍再来怼这个教程效率会高很多。我自己带过几个新人凡是顺序反了的最后都回来补 Python 基础反而更慢。1.3 教程真正的价值不是那个投票应用走完之后我最大的感受是官方教程的每个代码块都在传达 Django 团队的“推荐做法”而不是单纯给一个能跑的东西。比如它坚持让你先定义好模型再做迁移坚持用 URL 命名空间而不是写死路径坚持用get_object_or_404而不是自己 try/except。严格来说这些都不是功能必需但却是项目后期维护友好度的分水岭。所以如果你想从教程里提炼一点方法论那就是写 Django 项目的顺序应该始终围绕“数据模型 → 数据访问 → URL 路由 → 视图逻辑 → 模板呈现”这条链路去展开。不管项目多大多小这个骨架都不应该乱。后来我自己做任何新功能时都会先问一句“数据长什么样”而不是“页面长什么样”这一个习惯的改变就是官网教程给我的最大收益。2. 从零搭建项目最容易绕弯的几个环节2.1 环境准备版本选择与虚拟环境官网教程从创建虚拟环境开始。这一点我强烈建议不要跳过也不要图省事直接pip install django装到全局环境里。用python -m venv或者你习惯的虚拟环境工具把项目依赖和系统环境隔离这是后面所有工作的地基。我见过太多人因为全局环境里的 Django 版本和项目不一致排查一整天最后发现是环境问题。版本选择上教程对应的是当前稳定版现在主流教程已经跟着 Django 4.x 甚至 5.x 更新了。我的建议是直接装最新的稳定版但不要为了猎奇去装 alpha 或者 beta 版本。另外项目根目录下一定记得维护一份requirements.txt把自己安装的依赖和版本号固定下来。这一步教程不会刻意强调但真实项目里版本漂移引发的“在我电脑上能跑”问题十个里面有八个是因为没做依赖锁定。2.2 startproject 和 startapp 之间到底隔离了什么教程里这两个命令会让新手产生一个困惑为什么先建了 mysite 又建了一个 polls它们之间是什么关系我的理解是startproject创建的是“项目”负责配置、路由分发、部署入口可以把它想象成一个房子的总水管和配电箱startapp创建的是“应用”负责具体的业务模块相当于客厅、厨房这些功能区。一个项目里可以挂多个应用一个应用也可以被多个项目复用这才是 Django 推荐的组织方式。很多新手把所有代码往一个应用里塞后患无穷。mysite 目录下的settings.py、urls.py、manage.py分别是总配置、总路由和命令行入口。刚开始不用死记每个文件的作用但至少要理解manage.py是你和项目交互的主要通道后面所有操作几乎都从它出发。比如跑开发服务器、执行迁移、创建超级用户都是python manage.py xxx的格式。把它当成项目的“遥控器”会好记很多。2.3 第一份URL配置path与include官网教程在给 polls 应用配置第一条 URL 时用的方式是在项目urls.py里include应用自己的urls.py。很多新手会想为什么不直接在项目urls.py里写path(, views.index)理由其实很朴素把应用内部的路由放在应用自己的urls.py里项目只负责挂载前缀。这样 polls 这个应用可以整体搬到另一个项目里只要前缀一改就行如果所有路由都堆在项目urls.py里应用就失去了可复用性。你自己写项目的时候如果发现有多个应用但路由全在项目级文件里那基本可以判断组织方式出问题了。path函数里还有一个非常关键的东西转换器。教程里path(int:question_id/, views.detail)中的int:question_id会把 URL 中这个位置捕获成一个整数参数传给视图函数。这个看起来简单的语法实际上把类型转换和参数校验一起做了比自己去字符串截取要优雅得多。等你想做一个按 slug 显示的博客文章页时换成slug:slug就能达到同样效果。3. 模型与数据库官网教程里最值得反复咀嚼的部分3.1 为什么先写模型如果你之前习惯先画页面再写接口教程会立刻给你一个反向刺激先定义Question和Choice两个模型类然后立刻做迁移把数据表建好再去碰视图和模板。这个顺序背后是 Django 的核心思想数据是一切业务的起点。Question里有question_text和pub_dateChoice里有choice_text和votes并且用ForeignKey指向Question。这里我建议你仔细看一下 Choice 里的外键定义方式它会自动把一对多关系翻译成choice.question和question.choice_set其中choice_set是 Django 靠命名约定生成的子对象管理属性。理解了_set这个约定后面处理一对多、多对多关系都不会再慌乱。模型字段的类型也需要用心感受一下CharField、DateTimeField、IntegerField不只是简单的“数据类型声明”它们同时还决定了表单校验、admin 输入控件和数据库字段类型。比如DateTimeField在 admin 里会自动渲染日期控件而IntegerField会拒绝非数字输入。一个模型写对了后面很多层的代码都能省下来。3.2 迁移机制makemigrations 和 migrate 到底在做什么第一次跑python manage.py makemigrations polls之后教程会让你看看 migrations 目录下多了一个文件还展示了sqlmigrate能看到对应的 SQL。很多新手以为迁移就是把数据库建好其实迁移的精髓是把模型变化变成一份可追踪、可回滚的变更日志。实际项目里迁移文件的顺序是神圣的不要手工去数据库里改表结构也不要图省事删除迁移文件再重新生成尤其是项目上了多环境以后。你每一次字段变更都会在迁移历史里留下记录队友拉代码后只需要migrate就能把库表同步到一致状态。直白一点说迁移机制就是团队协作时保证数据库结构不改乱的保险丝。我见过太多人为了“省事”手工加字段然后所有人的环境都开始报 “no such column”最后只能靠对表结构硬核对。教程从第4部分开始还引入了字段约束的例子比如给Choice加UNIQUE约束防止同一个问题里出现重复选项文本。这种约束写在模型层比在视图里做 if 判断要可靠得多。数据库层面的边界越严应用层的代码就越简单。3.3 ORM查询与删除CRUD基本功教程在 shell 环节演示了创建、查询、过滤、删除这一整套 ORM 操作。这里我提两个常被忽略的知识点。第一Question.objects.filter(pub_date__yearcurrent_year)里双下划线__是 ORM 查字段、走关系的统一语法。改成pub_date__gte...就是大于等于改成choice__choice_text__startswithA就能从 Question 反向查询关联 Choice 的字段。这套语法熟悉之后写查询基本不需要记 SQL。我面试新人时只要看他能不能熟练说出几个__查询条件基本就能判断他有没有认真写过 Django 项目。第二删除操作。question.choice_set.all().delete()或者question.delete()的级联行为对应数据库中外键的 ON DELETE CASCADE。实操的时候要格外小心删除一个Question关联的Choice会被一并清掉Django 执行后还会提示你删除了多少条对象。这个行为在生产环境对数据的杀伤力很大所以批量删除之前一定要确认关联关系必要时用Collect外键的on_deletemodels.PROTECT来阻止误删。教程投票功能的代码里用到了F(votes)这是 Django 提供的原子递增写法读出来再加一再写回去在高并发下也不会丢更新。如果自己写choice.votes 1再 save()在并发请求时会有竞态问题。这个知识点在教程里很容易被当成小技巧跳过去但它其实是数据库并发安全的一个经典示例。凡是涉及“计数”“余额”“库存”这类字段都应该优先考虑用F()表达式。3.4 一个不得不说的坑时区教程里所有时间相关字段都用timezone.now()而不是datetime.now()。区别在于Django 开启USE_TZ True后所有时间都按 UTC 存储展示时才按本地时区转换。如果你在代码里直接塞了一个 naive 的本地时间轻则时间偏移几个钟头重则直接报错。这是教程里一笔带过但实际项目必踩的问题。建议从一开始就养成习惯所有模型里新增时间字段要么用auto_now_addTrue要么显式调用timezone.now()不要依赖datetime.now()。同时把TIME_ZONE设置成你业务面向的区域比如国内项目常设成Asia/Shanghai而USE_TZ保持True。这样存库和展示两边都不别扭。4. 视图、模板与URL把数据变成页面的完整链路4.1 函数视图到通用视图这一步为什么关键官网教程先让你手写index、detail、results三个函数视图代码量不长但模式高度重复查数据、传给模板、返回render。到了后面部分教程把这几个视图换成了ListView和DetailView通用视图代码一下子短了一大截。我起初觉得通用视图不好理解因为它的魔法成分太多类继承、类属性、默认命名约定一不小心就不知道它在渲染什么。后来我理解了通用视图的本质是把“单对象页面”“列表页”这类高频模板抽象出来你用特定名字的属性和约定它替你完成查询和渲染。教程里用了model Question和template_name polls/detail.html去接管默认行为这个思路值得延伸到自己的项目里凡是重复三轮以上的视图就该考虑抽通用视图或者 mixin不要一直复制粘贴。当然函数视图并不是要被抛弃。初期用函数视图把业务逻辑完整写一遍再对照通用视图来重构是最能理解“抽象”的方式。直接一上来就背通用视图的写法很容易变成“会套模板但不理解”遇到需要自定义查询集或上下文时就懵了。4.2 模板渲染与模板继承模板部分除了循环、变量、过滤器这些基础语法最该掌握的是模板继承。教程用polls/base.html搭了一个总架子子模板通过{% extends polls/base.html %}和{% block content %}填充内容。这和 CSS 里的抽公共样式是同一个思路公共的导航、页脚、头部只写一次。等你做有十几个页面的项目时没有模板继承的日子根本没法过。我在实操中养成的习惯是模板的相对路径前缀一定要带应用名比如polls/index.html否则两个应用里假如都有index.htmlDjango 的模板查找机制很可能让你踩到“渲染成别人的页面”的坑。这是教程不会强调但项目一多马上就会遇到的问题。另外模板里尽量只做展示逻辑复杂的业务计算应该放在视图或模型方法里否则模板越来越重维护成本直线上升。模板调试还有一个很实用的点Django 的报错页面会直接告诉你模板加载失败是在哪个目录找不到文件并且列出所有搜索过的路径。新手看到那一屏幕报错不要慌直接看最后的“Template-loader postmortem”那里基本已经把答案告诉你了。4.3 URL命名与reverse一次改动省下大量返工教程里给每个视图都起了 URL 名字并且通过app_name polls加上了命名空间。于是模板里就能写{% url polls:detail question.id %}而不是写死/polls/1/。这个做法的好处等你某天改了 URL 结构时才会真正体会到只要 URLconf 里name不变模板和视图里所有引用都不需要改动。反过来如果你把路径写死在模板里下次路径一调整就是全局搜索替换。配合视图里的reverse(polls:results, args(question.id,))URL 变成了一个可以反向解析的标识而不是一串脆弱的字符串。这对我来说是教程里最有“工程味”的提醒之一。再加上{% url %}在模板渲染时如果对应的 URL 名称写错会直接报NoReverseMatch异常这其实是个很好的保护机制它让 URL 错误在开发期就暴露而不是等到线上用户点击才发现链接 404。5. 表单、静态文件与Admin教程中暗藏的生产力工具5.1 处理POST请求的正确姿势投票功能要处理form methodpost教程的vote视图演示了完整的处理步骤从request.POST里取参数、查找对象、累加票数、保存、最后重定向。这里一定要留意两个细节。第一模板里必须带{% csrf_token %}否则 Django 会拦下 POST 请求。CSRF 防护是 Django 默认开启的它通过生成一次性 token 来防止跨站请求伪造新手经常因为这行缺失导致表单提交 403半天找不到原因。第二教程在处理“投票项不存在”时用了 try/except但更地道的写法其实是get_object_or_404它能帮你省掉异常分支语义也更清晰。视图里代码的分支数量是一个信号分支太多说明逻辑可以往下层或多个方法拆分。还有一个非常优秀的习惯是“POST 成功后必须重定向”。教程在投票成功后return redirect(polls:results, ...)避免用户刷新页面时重复提交表单。这个模式叫 Post/Redirect/Get是 Web 开发的经典规范。别看它简单很多新手包括曾经的我都会偷懒直接render一个结果页结果用户一刷新就重复投票。后来养成了“写 POST 视图先写 redirect”的习惯再没出过这种问题。5.2 静态文件为什么不能用全服务器路径教程部分引入了{% load static %}和{% static polls/style.css %}。它的好处在于开发环境的静态文件路径和生产环境经过collectstatic归拢后的路径可以完全不同模板里只有一个逻辑引用。很多新手会图省事直接在模板里/static/polls/style.css写死本地能跑一部署就开始报样式 404。Django 官方推荐的方式几乎就是为部署留出后路的建议从一开始就遵守。如果你还不太熟悉可以先把STATICFILES_DIRS指到项目根目录下的 static 文件夹把公共的 JS、CSS、图片统一丢进去管理。静态文件这块还有一个隐藏知识点开发时 Django 用runserver帮你托管静态文件但生产环境通常需要 Nginx 这类服务来托管并且用manage.py collectstatic把所有应用里的静态文件统一收集到一起。教程不会带你走完部署全流程但静态文件的引用方式就是在为这一步做准备。5.3 Admin后台教程里最被低估的模块到了自定义 admin 的部分我几乎是第一次意识到 Django 的 admin 不只是“自带的简易后台”而是一个可以快速搭建员工管理后台的生产力工具。教程演示了list_display、list_filter、search_fields、fieldsets以及StackedInline内联子表。我记忆里最深刻的是仅仅用声明式的列表和字典就能在几分钟内把后台从“白板”变成一个带筛选、搜索、分组编辑的界面。这里想多句嘴真实项目里admin 不是只能给 Django 超级管理员用。很多企业内部后台、运营系统、内容管理系统完全可以直接用 Django admin 加上权限控制来实现省掉一大块重复的前端开发。教程这一段如果你看懂并扩展后续会发现它比很多现成的“admin 脚手架”更灵活。尤其是结合热词里有人提到的unfold这类 UI 主题配好后整体观感也很现代完全没有早期那种“极客后台”的感觉。你还可以在 admin 里重写save_model方法在保存时自动填充操作人、更新时间或者对某些字段做额外的校验。这些扩展点教程只是开了个头但都值得自己动手试一遍。6. 做完官网教程不等于会做项目还差这几门实战课6.1 认证与登录官网教程缺席的第一课官网 Poll 教程从头到尾没有做登录注册。但任何一个真实项目第一件事就是谁在访问、有没有权限访问。Django 自带的django.contrib.auth提供了一套完整的基于 session 的认证体系包括 User 模型、登录/注销视图、login_required装饰器以及permission_required之类的权限判断。真实业务往往还要做“业务主体和账号绑定”比如一个投票应用应该允许“一个用户对同一个问题只投一次”。教程里没有这种需求但你可以立刻把它作为第一个扩展练习给 Choice 增加一个voters models.ManyToManyField(settings.AUTH_USER_MODEL)再在视图里判断当前用户是否已经投过票。做完这个练习你对认证和业务数据关联的理解会比看十篇博客都深。还有一个容易被忽略的坑Django 的默认 User 模型虽然能用但如果你预见到以后想给用户加手机号、昵称等自定义字段最好在项目一开始就通过AUTH_USER_MODEL换成自定义用户模型。这个决定越晚做越痛苦因为中途换用户模型需要非常复杂的迁移操作。6.2 cookie 与 token状态管理的两种思路教程告诉你 Django 如何在服务端存 session、客户端只拿一个 sessionid cookie。但现在的项目里前后端分离越来越多于是 JWT 之类的 token 方案也十分常见。我的建议是搞清楚二者各自的适用场景服务端渲染的传统页面用 session cookie 最简单Django 开箱即用如果前端是 SPA客户端和小程序共用接口那用基于 token 的认证更合适。实现上可以用djangorestframework-simplejwt把登录接口换成签发 access token 的逻辑。token 和 cookie 也不是二选一token 可以放在 HttpOnly cookie 里下发兼顾安全和跨端能力。cookie 的坑主要在属性上HttpOnly防止脚本读取、SameSite缓解 CSRF、Secure只允许 HTTPS。我在实际接口联调时经常发现前端明明能拿到 token但请求就是不带上排查到最后往往是 cookie 的SameSite属性没配好或者前端withCredentials没开。这些细节官网教程完全不会讲但联调时一定会撞上。6.3 权限模型为什么RBAC比“加个用户字段”更优网站后台永远绕不开权限设计。教程没讲但很多人搜 “django rabc”估计是在做后台权限。这里的建议核心是不要一上来就自己设计一套user.is_superuser加各种is_xxx_manager布尔字段的系统。RBAC基于角色的访问控制才是主流解法用户关联角色角色关联权限权限落在资源操作上。Django 自带的 Group 和 Permission 就是一套现成的 RBAC。你可以在 admin 里建“运营组”“编辑组”然后给每个组勾选对某个模型的 add/change/delete 权限视图里用user.has_perm做细粒度校验。等你的业务真的需要区分角色、职责、操作域时直接用这套机制会比自己维护一堆布尔字段干净得多。我在一个内容管理系统里吃过自定义权限模型的亏第一版需求只有一个“总编辑”和“普通编辑”我就加了个布尔字段三个月后要加“审核人”“作者”角色才意识到整套布尔字段已经覆盖不住了。如果一开始就上 Django 内置的Permission模型后面扩展会轻松很多。6.4 数据推送从轮询到WebSocket另一个常和 Django 关联搜索的场景是后台一有数据变化前端要马上收到。这里如果一个页面只是定时去拉GET /api/status就是轮询简单但浪费请求更好的体验是 WebSocket 这种长连接后端能主动把消息推给前端。Python 生态里做这件事的路线通常是给 Django 套上 ASGI再用 Django Channels 管理 WebSocket 连接业务完成后往 channel layer 里发送消息前端就能收到推送并更新页面。如果你只是想让“有后台数据时前端自动更新”也有一个过渡方案用 Server-Sent Events 单向推送。选择哪个取决于更新频率和是否需要前端回传消息通道。需要提醒的是WebSocket 的调试比普通 HTTP 麻烦得多。建议先把 HTTP 接口和业务逻辑全部调通再加推送层否则两边一起排查会很痛苦。我自己第一次做实时通知时业务逻辑没问题消息也发出去了但前端一直收不到最后发现是 ASGI 和 Channels 中间件顺序的问题。6.5 管理后台颜值不够试试第三方UI主题教程自带的 admin 界面偏“极客风”但实际做内部系统时大家总是希望后台好看一点。现在社区有不少基于 Django admin 的现代 UI 主题比如 unfold、django-admin-interface 这些装上之后配色、布局、暗色模式都有明显改善。我的观点是优先改样式不要轻易推翻 admin 重写前端。Django admin 的价值在于它的权限、表单验证、日志记录是现成的你只需要通过自定义 admin 类把展示和操作调整得贴合业务再配合第三方主题提升颜值投入产出比很高。我见过有人嫌 admin 丑直接做了一个独立 Vue 后台来对接同一套模型最后权限、日志、表单校验全都要重新造维护成本成倍增长。6.6 部署跑在开发服务器上不算完成教程全程用python manage.py runserver但它不能直接上生产。真实部署至少要考虑三件事静态文件收集collectstatic、应用服务器Gunicorn/uWSGI和反向代理Nginx再加上数据库迁移和日志。部署链路任何一个环节不熟项目就永远是“我能跑别人跑不了”。比较稳的学习路径是先在云主机上手动搞一遍看着 Nginx 转发请求给 Gunicorn、Gunicorn 加载你的 Django 应用并和数据库建立连接整个过程虽然琐碎但对整个 Web 请求生命周期会有一个不可替代的体感。如果一开始就图省事上 Docker Compose 一把梭反而可能漏掉很多概念。另外runserver在 DEBUGFalse 的情况下是不会托管静态文件的也不会对小错误做容错。很多人本地一切正常一关 DEBUG 就白屏基本都是因为静态文件没有collectstatic或者 ALLOWED_HOSTS 没配置好。这些问题部署一次就能记住但看教程永远记不住。7. 我的实战结果复盘与经验清单7.1 用什么样的节奏学完最舒服我个人的经验是官网教程拆成三个晚上比较合适第一晚做环境和模型第二晚做视图模板和表单第三晚做测试、静态文件和 admin。想一天啃完也可以但容易漏细节后面如果去扩展项目会发现很多概念是夹生的。学习过程中最好准备一个自己的扩展点比如把教程的投票改成“用筛选项过滤的不同排行榜”“把结果导出 CSV”等等。教程给出的是标准答案你自己改出来的部分才是真正内化的知识。我不建议直接复制粘贴代码哪怕先照着敲一遍再删掉重写一遍效果都会完全不同。7.2 我在教程外踩过的坑这个部分我想列几个复现概率极高的坑都是我实际遇到过的事。第一个坑是忘记迁移。改完模型不执行makemigrations结果在 admin 里找不到新字段或者在视图查询时报 “no such column”。解决办法是形成肌肉记忆模型一改立刻迁移两步走。第二个坑是模板路径。前面提过两个应用都叫index.html时模板查找很容易张冠李戴解决方案就是模板路径带应用名前缀并且命名得具备可读性。第三个坑是数据库驱动的选择。教程默认用 SQLite本地非常爽但部署后第一件事往往就是换 PostgreSQL。从第一天就在settings.py里用环境变量读取数据库配置会让你后面切换数据库时不用改代码。举个例子直接写死sqlite3数据库路径的配置换 PostgreSQL 时要动好几处用环境变量读取的话本地写.env服务器写系统环境变量代码完全不动。第四个坑是自定义用户模型的时机。如果你预感到以后要扩展用户字段就在第一次migrate之前把AUTH_USER_MODEL配好。这个决定最晚不要拖到项目上线后否则数据迁移会让你欲哭无泪。7.3 我沉淀下来的学习法既然这次是“实战结果复盘”我想把自己沉淀下来的学习和排查方法也说透。一个是“看报错但更要看文档和源码”。Django 的报错页面本身信息量很大调用栈、模板渲染位置、上下文变量几乎都在里面。有些问题搜索半天不如直接点开报错页面里的 Debug 信息。还有当某个 API 行为不符合预期时直接按住 Ctrl 点进源码看注释往往比看二手博客更准确因为文档偶尔滞后但源码永远是代码执行的真实依据。另一个是“每个官方链接我都顺手打开过”。Django 文档的索引和 API 参考写得很有条理你写一次QuerySet的 filter顺手把相关文档里的exclude、annotate、select_related都扫一眼比专门找一篇文章学效率更高。很多高级查询功能我就是这样在学教程的过程中顺手积累下来的后面做报表接口时用annotate直接省掉大量 Python 层循环。7.4 教程完成后怎么往前走最后我想聊聊“学完官网教程之后该做什么”。我的建议是立刻找一个自己感兴趣的领域做一个 2 到 3 张数据表的小项目例如图书管理、记账本、团队日程。做的时候延续教程里学的原则模型先行、URL 命名、表单用 POST、后台顺手配好把标准流程再走一遍。当你发现自己做的项目已经开始遇到教程没有覆盖的问题比如认证方式不匹配、数据访问频繁需要缓存、后台需要权限细分恭喜你那才是真正进入 Django 实战的起点。教程给的是地图走出来的路才是你自己的。后面无论你是继续深入研究 DRF 做接口还是转去学 Channels 做实时功能官方教程打下的这条标准工作流都会一直帮你兜底。