从零开始重新学习 Django：从 HTTP 开始的学习路线图
年终时，回顾过去一年总是自然而然的。对我来说，每年都会浮现一个主题——“我真的学会了 Django 吗？”
我已经使用 Django 和 Django REST Framework（DRF）多年，经历了大小项目。现在我可以自信地说：
“我已经能清晰地把握各个组件的工作原理，比以前更有感觉。”
当然，仍有许多未知之处。但至少我能对过去的自己，也能对刚起步的开发者说：“按这个顺序学习，路会更顺畅。”
本文正是在这种背景下写成的，旨在为想从零开始重新学习 Django 的人提供个人化的指导。它既像年终回顾，也希望成为任何时候都适用的 Django 学习基准。
1. Django 最终是一个 HTTP 框架
这听起来很显而易见，但刚接触 Django 时往往会忽略这一点。
无论是渲染 UI，还是仅返回 JSON API，核心都是 接收 HTTP 请求并返回 HTTP 响应。
- 客户端（浏览器、App、其他服务器）发送 HTTP 请求。
- Django 接收请求并进行相应处理。
- 最后返回 HTTP 响应（HTML、JSON、文件、错误等）。
我们常提到的 Django 组件：
- URLConf
- View（FBV/CBV）
- Template
- ORM
- Middleware
- Authentication / Permission
- DRF 的 Serializer、ViewSet、Router…
所有这些，实质上都是 “如何正确接收、处理并返回 HTTP 请求” 的工具。
如果忽视了这一视角，框架很快会变成 “魔法盒子”：
“只要按这种写法就行…但到底为什么会这样？”
如果这种状态持续下去，最终会被框架牵着走。
2. 先理解“为什么这么做”，再关注功能
刚学 Django 时，往往会被以下功能吸引：
- 登录/注册、社交登录
- 权限/授权
- 缓存设置
- 异步任务（Celery 等）
- 各种中间件与配置
这些功能确实在后期需要，但如果 过早 深入，往往会出现：
“为什么要这么做？”
在无法回答这个问题的情况下堆砌代码，结果会出现：
- 修复错误后仍有不舒服的感觉
- 每次想改结构都被框架束缚
- 直接复制粘贴 Google 搜索结果，进入 “先能用再改” 模式
所以给过去的自己，也给刚起步的开发者的第一句话是：
“先理解 Web 的工作原理和 HTTP 的流程，再去使用功能。”
3. 理解 HTTP 流程，让 Django 的外部也清晰可见
想要“透明”地使用 Django，必须先掌握 HTTP 协议的基本流程。
至少可以亲手操作以下内容：
- 请求的结构：URL、方法（GET/POST/PUT/DELETE…）、Header、QueryString、Body
- 响应的决定因素：状态码（200/400/404/500…）、Header、Body（JSON/HTML 等）
- 浏览器缓存与服务器关注点
举个简单例子：在终端直接发送请求。
curl -X GET "http://localhost:8000/articles/1/" -H "Accept: application/json"
这条请求已经包含了 HTTP 的核心要素：
- URL：
/articles/1/ - 方法：
GET - Header：
Accept: application/json - 期望返回 JSON
当你把这整个流程在脑中绘制出来后，Django 的外部也会随之显现：
- 为什么 nginx 会把某些路径代理到 Django
- gunicorn/uWSGI 等 WSGI 服务器的角色
- Django 负责哪些，哪些交给了其他层
到此，Django 不再是“未知的魔法”，而是 “为处理 HTTP 请求而设计的结构”。
4. 第一个项目保持简单，用 FBV 开始
在 Django 入门时，我最推荐的做法是：
第一个项目保持简单，使用 Function-Based View（FBV）。
尽量满足以下条件：
- 认证/权限最小化
- 管理页面或设置不复杂
- 模型关系简单（如文章、评论）
- 关注“工作流程”，而非“漂亮结构”
举例：用 FBV 实现一个简单的文章列表/详情。
# views.py
from django.http import JsonResponse
from .models import Article
def article_detail(request, pk):
article = Article.objects.get(pk=pk)
data = {
"id": article.id,
"title": article.title,
"content": article.content,
}
return JsonResponse(data)
这一个视图就包含了 Django 的核心流程：
- 接收
request对象。 - 用 ORM 根据
pk查询数据。 - 构造 Python 字典。
- 将其包装成 HTTP 响应（JSON）。
逐行调试时，你会看到：
- URLConf 如何映射到视图
request对象包含哪些信息- ORM 生成的 SQL
- 响应如何被序列化为 JSON
在此阶段熟练掌握 Django ORM，后续任何规模的项目都会受益匪浅。
5. 接下来快速切换到 CBV 与 DRF
当你已经用 FBV 体会到 HTTP–View–ORM–Response 的完整流程后，第二个项目可以毫不犹豫地使用 CBV 和 DRF。
这时，你会真正感受到 Django 的强大与 DRF 的便利。
CBV 与 DRF 的价值：
- 减少重复模式，提供可复用结构
- 统一项目整体的设计模式
- 明确职责分离
- 通过 URL/Serializer/ViewSet/Permission 的耦合实现可扩展设计
示例：将同一功能迁移到 DRF。
# views.py (DRF)
from rest_framework.viewsets import ReadOnlyModelViewSet
from .models import Article
from .serializers import ArticleSerializer
class ArticleViewSet(ReadOnlyModelViewSet):
queryset = Article.objects.all()
serializer_class = ArticleSerializer
只需注册路由：
# urls.py
from rest_framework.routers import DefaultRouter
from .views import ArticleViewSet
router = DefaultRouter()
router.register(r'articles', ArticleViewSet, basename='article')
urlpatterns = router.urls
现在：
/articles//articles/{id}/
这两个端点会自动工作。
如果你已经理解了 FBV 的 HTTP 流程，CBV/DRF 的“魔法”其实只是把同样的流程抽象成类。
“原来在内部也在跑同样的 HTTP 请求/响应流程，只是被封装成了类。”
把 CBV/DRF 看作 “已知的 HTTP 处理流程的抽象工具”，比把它们当作“必须记住的语法”更容易吸收。
6. Django 学习顺序整理
给过去的自己，也给刚起步的开发者，我建议的学习顺序如下：
- Web 与 HTTP 基础
- 浏览器–服务器的请求/响应流程
- HTTP 方法、状态码、Header、Cookie、Session
- 用
curl或 Postman 发送请求 - Django 基础：用 FBV 循环一次 - URLConf–View–Template–ORM 的基本流程 - 完成一个无认证/权限的小项目 - 用 ORM 直接实现 CRUD
- 深入 Django ORM 与 Admin - 模型设计、关系（ManyToOne、ManyToMany）、查询优化 - 用 Admin 管理数据，熟悉模型结构
- 转向 CBV - 用 Generic View 重写 CRUD - 观察 Mixin、继承结构，感受“模式抽象”
- 用 DRF 做 API 项目 - Serializer、ViewSet、Router、Permission、Authentication - 把 FBV/CBV 的功能迁移到 DRF
- 再往后做“炫酷功能” - 认证/授权、节流、分页、过滤 - 缓存、异步任务、部署、扩容
关键是：每一步都能自我解释“为什么这么做”。不是“因为这样写”，而是“因为 HTTP 与 Web 的结构决定了这样做更自然”。
7. 结语：不要记住框架，记住 Web
最后，我想留给过去的自己和刚起步的开发者一句话：
不要记住框架，记住 Web 的工作原理。
Django 只是帮助你理解这一点的优秀工具。
只要保持这个视角，你就能：
- 即使 Django 版本变更，也能快速适应
- 轻松切换到 Flask、FastAPI、Node、Spring 等框架
- 在新的架构或云环境中保持一致的思考方式
你可以随时问自己：
- “这个系统是如何处理 HTTP 的？”
- “谁负责什么？”
- “抽象层到底隐藏了哪些请求/响应模式？”
有了这些标准，你就不会被任何框架束缚，能在任何环境中成为稳定的 Web 开发者。
目前没有评论。