從零開始重新學習 Django：以 HTTP 為起點的學習路線圖
每到年底，回顧過去一年總會不自覺地想起一個主題：「我真的學會了 Django 嗎？」
我已經使用 Django 與 Django REST Framework (DRF) 數年，經歷了大小專案。現在我可以說：
「我已經能夠把握它的運作方式，感覺比以前清晰多了。」
雖然仍有許多未知，但我已經能夠對過去的自己以及剛踏入 Django 的開發者說：「按這個順序學習，會少走許多弯路。」
本文正是在這樣的背景下撰寫，提供一份個人化的 Django 從零學習指南。閱讀時不妨把它當作一份年度回顧，也可隨時參考，成為你學習 Django 的基準點。
1. Django 最終是處理 HTTP 的框架
雖然這句話聽起來很顯而易見，但在學習初期往往會被忽略。
Django 的核心是：接收 HTTP 請求，並回傳 HTTP 響應，不論是渲染 UI、返回 JSON API，或是傳送檔案。
- 客戶端（瀏覽器、App、其他伺服器）發送 HTTP 請求。
- Django 接收並處理。
- 最後回傳 HTTP 響應（HTML、JSON、檔案、錯誤訊息等）。
我們常提到的 Django 元件：
- URLConf
- View（FBV/CBV）
- Template
- ORM
- Middleware
- Authentication / Permission
- DRF 的 Serializer、ViewSet、Router…
這些都是為了「順利處理 HTTP 請求」而設計的工具。若忽略這一觀點，框架很快就會被視為「魔法盒子」。
「只要照這樣寫就行…但為什麼會這樣運作？」
若長期保持這種狀態，最終會被框架牽著走。
2. 先理解「為什麼」再學「功能」
初學者往往會被以下功能吸引：
- 登錄/註冊、社群登入
- 權限/授權
- 快取設定
- 非同步任務（Celery 等）
- 各種 Middleware 與設定
這些功能確實在後續需要，但若過早深入，會產生以下問題：
- 修正錯誤時仍感到不安
- 想改結構時被框架束縛
- 直接貼上 Google 搜尋結果，進入「先做就好」模式
因此，對於過去的自己與剛起步的開發者，我想說：
先理解網頁運作原理與 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 查詢資料
- 建立 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 請求/回應流程，只是以更抽象的方式呈現。」
若遇到不明白的地方，別忘了可以深入 Django 內部源碼，觀察其結構。
6. Django 學習順序總結
對於過去的自己與剛起步的開發者，我建議的學習順序如下：
- 網頁與 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 與網頁結構需要這樣」。
7. 結語：不要只記住框架，理解網頁
最後，我想留給過去的自己與剛起步的開發者一句話：
不要只記住框架，理解網頁如何運作。
Django 只是幫助你理解的工具。只要保持這個觀點：
- Django 版本更新
- 遇到 Flask、FastAPI、Node、Spring 等
- 接觸新架構或雲端環境
你都能以同樣的標準提問：
- 「這個系統如何處理 HTTP？」
- 「哪裡負責什麼？」
- 「這個抽象究竟隱藏了哪些請求/回應模式？」
有了這個基準，你就不會被任何框架束縛，能在任何環境中成為穩定的網頁開發者。
目前沒有評論。