Django vs FastAPI：Cloudflare Workers 上到底该选谁？

Django vs FastAPI：Cloudflare Workers 上到底该选谁？

已有 Django 应用，或需要完整的产品后端，就选 Django；从零开发类型化 API、Webhook 服务或 I/O 密集型边缘端点，就选 FastAPI。 如果必需依赖、进程模型或有状态负载不适配 Workers 运行时，则无论使用哪个框架，都应让应用继续留在现有源站。

Cloudflare 在 2026 年 9 月 2 日改变了这道题的前提。借助 workers 模块中的适配器，Python Workers 现在可以直接承载 WSGI 和 ASGI 应用。WSGI 是 Python Web 传统的同步接口规范；ASGI 则是面向并发 I/O、流式传输和长连接的异步后继者。Cloudflare 发布时给出的示例 明确将 Django 与 WSGI、FastAPI 与 ASGI 配对，不过 Django 实际上两种协议都能使用。

如果 Django 已经承载着有价值的产品能力，它就是风险更低的迁移方案。Cloudflare 目前同时提供 WSGI 与 ASGI 入口文档，还给出了通过 django-cf 接入 D1 和 Durable Objects 的路径。

如果从零交付的是 API，而不是依赖管理后台的 Web 产品，FastAPI 更干净直接。ASGI 服务层由 Cloudflare 提供，因此 Worker 无需运行 Uvicorn，也不必自行管理套接字。

价格暂时平手，直到 CPU 时间拉开差距

两个框架在价格上谁都没有优势。 相关费用已于 2026 年 9 月 5 日对照仍在线的一手页面核验：Django 是免费开源软件，采用 BSD 许可证；FastAPI 采用 MIT 许可证；Workers Paid 每个账户每月 $5 起。

这 $5 每月包含 10 million 次请求和 30 million CPU 毫秒。超出后，请求按每 million 次 $0.30 收费，CPU 按每 million CPU 毫秒 $0.02 收费。Static Asset 请求免费且不限量。Workers Free 每天包含 100,000 次请求，但每次调用只有 10 ms CPU 配额，并不适合作为非简单框架应用的比较基线。

把两个框架放进同一负载模型，结果刻意得有些平淡：每月 15 million 次动态请求、每次请求平均占用 7 ms CPU 时，无论选哪一个，月费都是 $8，其中包括 $5 基础费、$1.50 请求超额费和 $1.50 CPU 超额费。请求量升至 100 million、平均 CPU 仍为 7 ms 时，两者的月费同为 $45.40。

与其编造框架基准，不如做敏感性计算。两个应用都耗尽内含 CPU 配额后，平均 CPU 每相差 1 ms，在 15 million 次请求时会让账单相差 $0.30，在 100 million 次请求时则相差 $2。因此，实测差距若为 5 ms，对应的月度价值分别只有 $1.50 和 $10。仅凭计算费用，这点差额远不足以支持一次框架重写。

这里不存在供应商定价上的交叉点。只有实测 CPU 时间、配套服务或维护负担不同，其中一个方案才会更便宜。框架再快，也救不了被慢数据库调用拖住的架构；反过来，集成式框架若能省去数周的替换工作，即便微基准测试偏向另一方，整体成本也可能更低。

迁移路径：旧系统选 Django，新 API 选 FastAPI

适配器的改动很小，应用迁移却绝不轻松。 两个框架都只需要一层很薄的入口，但入口之后的所有东西，仍必须适配 Cloudflare 对依赖包、存储、文件系统和生命周期的约束。

Django 迁移到 Cloudflare Workers：适配器反而最简单

Django 可以保留标准 WSGI 应用对象，再交给 Cloudflare 的适配器：

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

这样就足以把进入 Workers 的请求转交给 Django 的 WSGI callable。但它不会替你迁移数据库、持久化文件、定时任务和会话策略，也无法保证每个第三方 Django 包都能直接运行。

Cloudflare 新发布的 Django 包指南 为该框架提供了一条真正原生的存储路径。django-cf 包为 D1 和 Durable Objects 提供兼容 SQLite 的后端。两者都驱动 Django 的同步 ORM，因此 Cloudflare 要求这套配置通过 WSGI 提供服务。对于已经依赖模型、表单、认证和管理后台的 CRUD 产品，保住这些层所节省的工作，远多于更换框架可能省下的运行成本。

真正的障碍出现在现有系统默认自己运行在传统服务器上时：数据库驱动可能依赖 Workers 无法加载的原生 wheel；用户上传内容不能留在隔离实例的文件系统中；进程内调度器或线程池也无法原样搬过去。所谓支持 Django，只说明请求协议可以工作，并不等于整套已安装应用都获得了兼容认证。

FastAPI 迁移到 Cloudflare Workers：更适合边界清晰的服务

FastAPI 原生采用 ASGI，因此直接适配所需代码更少：

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

原本由 Uvicorn 承担的 ASGI 服务器角色，现在由 Cloudflare 提供。FastAPI 仍保留路由声明、Pydantic 校验、依赖注入和自动生成的 OpenAPI 文档。于是，新建 Webhook 接收器、类型化 JSON API 或基于绑定的服务时，引入的应用机制会比 Django 更少。

代价是需要自己组装。FastAPI 有意不规定数据库和数据模型，也不自带 Django 那样的内容管理后台。团队必须自行挑选这些组件，逐个检查其与 Workers 环境的兼容性，并负责集成。对于目标单一的服务，这是优势；对于运营人员从第一天就需要后台的产品，这就是额外成本。

迁移胜负： 已经使用 Django 的应用继续选 Django；新建 API 选 FastAPI。仅仅因为两者现在都能运行在边缘，就把运转良好的 Django 系统改写为 FastAPI，是选错了项目。

WSGI 和 ASGI 怎么选：FastAPI 胜在并发，Django 保留两种路径

新建 I/O 密集型服务时，ASGI 是更强的请求模型；但对 Django 的 Cloudflare ORM 集成而言，WSGI 才是官方文档给出的路径。 协议应由负载决定，而不是由“异步永远更快”这样的泛化说法决定。

WSGI 将应用呈现为同步 callable。Cloudflare 的当前 WSGI 适配器 会在 Worker 的异步 fetch 处理程序内运行这个 callable：它从 JavaScript ReadableStream 桥接请求体，再把应用返回的可迭代响应以流式方式发回客户端。这是成熟同步应用的兼容路径，并不是在隔离实例里又运行了一台 Web 服务器。

借助 ASGI，应用可以等待网络和存储操作，而不必用同步调用占住请求路径。Cloudflare 的适配器还会把 ASGI WebSocket 事件映射到 Workers WebSockets。FastAPI 生来就基于这一模型；Django 也可以使用它，所以不能把“Django”和“WSGI”画上等号。

存储方案有时会反过来决定协议。Cloudflare 明确表示，Django 的 D1 与 Durable Objects 后端都驱动同步 ORM，应通过 WSGI 对外提供服务。如果选择 Django 的理由就是它的 ORM，那么遵循这条官方 WSGI 路径，要比给同步数据层强贴 ASGI 标签更合理。

对 FastAPI 而言，只有任务能够重叠执行，异步才会带来收益。如果端点的大部分时间都耗在串行校验或 CPU 密集型 Python 代码上，CPU 用量并不会消失。若端点需要等待多个相互独立的 HTTP 请求或 Cloudflare 绑定操作，选择 ASGI 才有更充分的理由。

启动行为：FastAPI lifespan 的意外之处

目前在 Workers 上，Django 配合 WSGI 的启动模型更可预测。 FastAPI 当然可以正常工作，但它的 lifespan 钩子并不像长期运行的 Uvicorn 进程那样执行。

Cloudflare 通过部署快照减少 Python 冷启动工作。部署期间，平台会创建 V8 隔离实例、注入 Pyodide、执行 Worker 入口模块及其顶层 import，然后为 WebAssembly 内存创建快照。处理请求时可以直接加载该快照，不必从零重建 Python 环境。不过，全局作用域代码仍须在平台规定的 1 秒启动限制内完成解析和执行。Cloudflare 对这套生命周期有直接说明。

FastAPI 的常规 lifespan 契约以进程为单位：应用开始接收请求前执行一次启动代码，结束后再执行一次关闭代码。但 Cloudflare 当前 ASGI 适配器的源码 有实质差异：它的 fetch 函数启动 ASGI 应用，发送 lifespan 启动事件，处理一个请求，随后发送关闭事件。源码注释描述的正是请求前后各执行一次启动和关闭的周期。

也就是说，在当前适配器中，lifespan 代码实际上变成了请求级逻辑。放在其中的模型加载、连接池创建、schema 预热或远程配置获取，可能会重复发生，而不是由一个隔离实例分摊。这并不是放弃 FastAPI 的理由，但它要求 lifespan 内的工作既轻量又幂等；安全且确定性的初始化，则应移到能够利用 Cloudflare 部署快照的代码中。

在 Cloudflare 示例里，Django 的 WSGI 应用于模块作用域创建，不存在 ASGI lifespan 周期。因此，它的初始化属于全局启动路径，约束变成了 1 秒上限。如果选择 Django 的 ASGI 入口并使用了感知 lifespan 的组件，也要依据同一适配器行为进行审计。

Cloudflare Workers Python 框架面对同一堵依赖墙

这一项同样打平，而且它可能直接淘汰两个框架。 Django 和 FastAPI 都运行在 V8 内的同一套 Pyodide 环境中，谁也绕不过依赖包、内存、文件系统和启动边界。

Cloudflare 的依赖包文档 表明，pywrangler 会打包 pyproject.toml 中声明的依赖。支持的来源包括 PyPI 上的纯 Python 包与 PyEmscripten 包，以及 Pyodide 自带的包。PyEmscripten 是面向 WebAssembly 目标的 wheel 格式。Cloudflare 仍将这一生态描述为早期阶段，一些软件包并没有兼容 wheel。

平台的硬性检查项非常明确：

• 无论 Free 还是 Paid，Worker 解压后的包体积都不能超过 64 MiB。
• 每个隔离实例拥有 128 MB 内存。
• 全局作用域启动必须在 1 秒内完成。
• Python 文件系统是临时的，且仅对当前隔离实例可见。
• threading 和 multiprocessing 可以导入，但无法在 WebAssembly VM 中运行。

相比适配器签名，文件系统这一点会让更多迁移失败。临时文件没有问题，但持久化上传内容、生成的报告、作为持久状态的 SQLite 文件以及共享磁盘缓存都不可行。持久对象应按访问模式放进 D1、Durable Objects、KV 或 R2，而不是写入随隔离实例一起消失的目录。Cloudflare 的 Python 标准库指南 记录了具体边界。

在讨论性能前，依赖兼容性首先是一个非黑即白的问题。必须构建真实的完整依赖图，而不是只测试 hello-world 子集。在桌面版 CPython 中成功 import，完全不能证明对应原生扩展在 Pyodide 中可用。

运维适配度：产品选 Django，服务选 FastAPI

工作单元是“产品”，Django 占优；工作单元是“服务”，FastAPI 占优。 这一区别比合成路由上的框架吞吐量更经得起时间考验。

需要管理后台的产品：Django 胜出

Django 将用户认证、内容管理后台、ORM、模板、中间件以及其他常见 Web 产品能力打包在一起。它的官方概览明确提到了认证与内容管理。如果小型运营团队需要管理客户、订单、权限和编辑记录，内置后台的价值可能远高于从框架开销中省下的几毫秒。

在 Workers 上，django-cf 为这套集成模型提供 D1 或 Durable Objects 路径，代价则是与同步 ORM 耦合更紧，并且要让更大的框架体量适配运行时限制。

类型化 API 服务：FastAPI 胜出

FastAPI 围绕 OpenAPI、JSON Schema、Pydantic 校验和依赖注入构建。它的功能文档也明确体现了相应取舍：数据库和数据模型完全开放。对于 API 网关、Webhook 接收器、模型端点，或与绑定及远程 API 通信的小型服务，这正是合适的形态。

如果服务不需要集成式管理后台和 ORM，缺少它们并不是缺点。一旦非技术运营人员需要后台，这些缺口就会转化成交付成本。

原始速度谁最快：Workers 上尚无定论

据 FastAPI 的基准测试页面所述，TechEmpower 的独立测试套件过去一直将 Uvicorn 下的 FastAPI 列为速度最快的 Python 框架之一。TechEmpower 测量了标准化的 JSON、数据库、ORM、模板等负载，却没有测试 Cloudflare 的 Pyodide 适配器；而且该项目已于 2026 年 3 月 24 日终止。因此，这些结果只是有来源可查的历史信号，不能用来预测 Workers 部署表现。

Cloudflare 尚未发布通过这些适配器运行 Django 与 FastAPI 的对比基准。只有代表性路由纳入自身的数据校验、绑定、数据库调用、响应结构、启动行为和 Workers CPU 指标后，才能判断真实速度；在此之前，Workers 上谁更快仍无证据。

切换框架究竟要付出什么，哪些团队不该切换？

不要只为获得 Cloudflare 支持而切换框架，因为两者现在都已获得支持。 只有目标框架能减少的应用工作多于迁移新增的工作时，切换才成立。

从 Django 重写为 FastAPI，意味着替换或拆分模型、迁移机制、管理页面、认证流程、中间件、模板，以及所有依赖 Django 请求生命周期的软件包。对于边界清晰的 API，最终结果可以很好，但这绝不是改一下部署配置。如果管理后台和 ORM 使用很深，切换会先摧毁已有杠杆，再谈创造价值。

只有当产品已经不再适合服务型架构，并且确实需要 Django 的一体化运营能力时，从 FastAPI 转向 Django 才说得通；否则只是给小型 API 加上它并不需要的约定与组件。

FastAPI 可以通过 a2wsgi.WSGIMiddleware 在某个路径下挂载 Django WSGI 应用。在传统服务器上，这可以支持分阶段拆分；到了 Workers，它会再引入一个依赖和一道协议边界，而 Cloudflare 的入门方案分别记录了两个框架。组合 Worker 应被视为需要验证的定制集成，而不是默认捷径。

无论考虑向哪个方向切换，都要核算以下迁移面：

• 数据： schema 兼容性、迁移、事务行为，以及迁往 D1、Durable Objects 或其他可访问存储的工作。
• 文件： 静态资源可以使用 Workers Static Assets，持久化用户媒体则需要 R2 之类的持久对象存储。
• 后台工作： 用平台原生异步工作机制替换进程内调度器、线程池和子进程。
• 依赖： 根据 Python Workers 解析完整 lockfile，再检查 64 MiB 包体积和 1 秒启动结果。
• 运维： 重新建立日志、错误告警、部署回滚、密钥管理以及路由级性能基线。

哪些团队不该切换？数据库运行稳定、管理后台流程成熟的 Django 单体，不应为了追逐潮流而改成 FastAPI。依赖不可用原生 wheel 的 FastAPI 服务，也不应只因为框架新多了一页文档就迁往 Workers。如果延迟主要来自远端数据库，团队首先该解决的是数据位置，而不是请求框架。

下周一就做这件事

下周先验证一条有代表性的路由，不要一上来搬整个应用。 选择一条能够代表生产系统依赖、状态和延迟特征的路由，用它迅速淘汰错误选项。

Cloudflare Workers 上 Django 与 FastAPI 常见问题