Cloudflare Python Workers 支援 Django、Flask：WSGI 與 ASGI 怎麼選？

先按 framework 選 WSGI 或 ASGI#

WSGI 和 ASGI 是應用程式與 web server 之間的介面。你不需要自己在 Worker 裡開 socket，但必須讓 Workers runtime 使用正確的 adapter，否則最小路由可能能啟動，實際 middleware 或非同步處理卻會在請求時出錯。

Cloudflare 的 Python Workers 公告也用同一個方向區分：Django、Flask 使用 WSGI，FastAPI、Starlette 使用 ASGI。不要因為 ASGI 聽起來比較新，就把所有 Django 專案直接改成 ASGI。 先用現有依賴和實際請求路徑做一個最小驗證。

先用官方範本啟動 Django#

如果你要評估 Django，官方文件提供了可以直接建立專案的範本。先在隔離資料夾執行：

1
uv run pywrangler init django-worker \
2
  --template https://github.com/cloudflare/python-workers-examples/tree/main/django
3
cd django-worker
4
uv run pywrangler dev

先用 curl 或瀏覽器確認首頁，再把自己的 settings、middleware 和資料庫設定逐項搬入。這個順序能把「Workers adapter 問題」與「原專案設定問題」分開，不會一開始就被完整 production 設定淹沒。

Flask：用 WSGI adapter 接最小路由#

Cloudflare 的 Flask 範例可以縮成下面這個 Worker。Default 是交給 Workers runtime 的 entrypoint，Flask 的 app 則仍然是原本的 WSGI application：

1
from flask import Flask
2
from workers import wsgi
3

4
app = Flask(__name__)
5

6

7
@app.get("/")
8
def index():
9
    return {"message": "Hello from Flask"}
10

11

12
Default = wsgi.entrypoint(app)

本機啟動使用 uv run pywrangler dev。第一個測試不要先接資料庫或大型前端，先確認 status code、JSON response、錯誤處理與一個需要 request context 的 route 都正常，再增加 blueprint、extension 和 template。

Django：WSGI 與 ASGI 只差一個 adapter，驗證範圍不只一行#

Django 的 WSGI 版本可以使用 get_wsgi_application()：

1
import os
2

3
from django.core.wsgi import get_wsgi_application
4
from workers import wsgi
5

6
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
7

8
app = get_wsgi_application()
9
Default = wsgi.entrypoint(app)

如果專案確實要走 ASGI，改用 get_asgi_application() 和 workers.asgi：

1
import os
2

3
from django.core.asgi import get_asgi_application
4
from workers import asgi
5

6
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
7

8
app = get_asgi_application()
9
Default = asgi.entrypoint(app)

Cloudflare 的 Django 文件指出，Python Workers 對 ASGI 做了最佳化，但 WSGI 仍與 Django 相容。這代表選擇時應看專案的實際同步／非同步邊界，而不是只看 adapter 名稱。

若使用 Cloudflare 文件提到的 django-cf，D1 和 Durable Objects backend 會驅動同步 Django ORM，應先走 WSGI 路徑；文件也提醒這些 backend 不支援 Django transaction。這不是 adapter 可以補上的差異，必須在資料層測試中明確記錄。

Secret 和靜態資產要分開處理#

不要把 SECRET_KEY 或其他 production 值寫進 settings.py 並提交到 repository。Django 在 Workers 上可以從 Worker secret 讀取：

1
from workers import env
2

3
SECRET_KEY = env.DJANGO_SECRET_KEY

再用 Wrangler 建立 secret：

1
uv run pywrangler secret put DJANGO_SECRET_KEY

如果 Flask 前面還有獨立的前端，Cloudflare 的文件建議用 Workers Static Assets，並透過 run_worker_first 讓 API route 先交給 Worker 處理。設定檔可先從這個最小片段開始：

1
{
2
  "assets": {
3
    "directory": "./public/",
4
    "binding": "ASSETS",
5
    "run_worker_first": true
6
  }
7
}

這樣做的好處是前端檔案不必全部塞進 Worker bundle；但仍要測試 unmatched path、404、cache header 和 API／資產路由衝突，不要只確認首頁有出現。

部署前用這份清單收斂風險#

Python Workers 目前仍在 Cloudflare 文件的 Beta 分類中，第一次採用時應把 runtime 相容性當成部署條件，而不是把本機 Python server 能啟動視為完成。

如果只想先證明「框架能不能跑」，先完成一個無資料庫的 Flask 或 Django route；如果目標是把既有服務搬上去，再把資料庫、背景工作、檔案上傳和 observability 拆成獨立驗證項目。邊緣 runtime 的成功標準應是每一個依賴都能被說明，而不是只有 pywrangler dev 沒有報錯。

結論：先對齊 protocol，再處理 runtime 差異#

Cloudflare Python Workers 支援 WSGI 和 ASGI，降低了 Django、Flask、FastAPI 與 Starlette 評估時的接入門檻，但不會消除 Python runtime 與傳統伺服器的差異。先按 framework 選 adapter，用官方最小範例跑通，再獨立驗證 secret、靜態資產、資料庫與套件相容性，會比直接搬整個 production 專案更容易定位問題。

常見問題#