Cloudflare Python Workers 正式进入 GA，变化不只是“现在可以用 Python 写一个边缘函数”。更关键的是，Python 已经接入 Workers 的完整平台能力：FastAPI、Django、Flask 可以沿用熟悉的框架结构，应用也能通过绑定访问 Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues 和 Workflows。
对于已有 Python 服务的团队，这意味着迁移重点从“如何把请求翻译成 Worker 能理解的格式”，转向“哪些依赖和运行时假设适合边缘环境”。
GA 真正解决了什么
过去把 Python Web 应用放到非传统服务器环境，往往要维护一层胶水代码：解析平台事件、构造框架请求对象、转换响应，再单独处理数据库和对象存储凭证。
Python Workers 将这部分职责收进运行时和框架适配层。以 FastAPI 为例，应用仍然定义路由、路径参数和响应模型，Worker 入口只需要把请求交给 ASGI 适配器：
class Default(WorkerEntrypoint):
async def fetch(self, request):
return await asgi.fetch(app, request, self.env)
这里的 self.env 是平台绑定入口。应用不必自己读取 R2、D1 等服务的访问密钥，也不必通过公网 HTTP 绕一圈访问同一平台上的资源。
底层仍不是一台持续运行的传统 Python 服务器。Python Workers 基于 Workers 隔离环境运行 Python，技术路径与 Pyodide、WebAssembly 和 V8 isolate 有关。因此，“支持 Python”不等于“拥有一台可以任意启动进程、写本地磁盘或安装系统动态库的 Linux 主机”。GA 提升的是可用性、兼容性和平台承诺，并没有抹平边缘运行时与服务器之间的差异。
用 FastAPI 跑起一个最小 Worker
下面是一套可以直接创建并改造的最小项目。运行前需要安装 Node.js，并准备一个 Cloudflare 账号；本地开发可以先不登录。
mkdir fastapi-edge-api
cd fastapi-edge-api
npm init -y
npm install --save-dev wrangler
mkdir -p src
cat > wrangler.jsonc <<'EOF'
{
"$schema": "node_modules/wrangler/config-schema.json",
"name": "fastapi-edge-api",
"main": "src/entry.py",
"compatibility_date": "2024-03-20",
"compatibility_flags": ["python_workers"]
}
EOF
cat > requirements.txt <<'EOF'
fastapi
EOF
cat > src/entry.py <<'EOF'
from fastapi import FastAPI
from workers import WorkerEntrypoint
import asgi
app = FastAPI(title="Edge Catalog API")
@app.get("/")
async def root():
return {
"service": "fastapi-edge-api",
"runtime": "cloudflare-workers",
}
@app.get("/products/{product_id}")
async def get_product(product_id: int, currency: str = "CNY"):
return {
"id": product_id,
"currency": currency,
"available": True,
}
class Default(WorkerEntrypoint):
async def fetch(self, request):
return await asgi.fetch(app, request, self.env)
EOF
npm pkg set scripts.dev="wrangler dev"
npm pkg set scripts.deploy="wrangler deploy"
npm run dev
开发服务器启动后，可以在另一个终端验证路由：
curl http://localhost:8787/
curl 'http://localhost:8787/products/42?currency=USD'
准备部署时执行：
npx wrangler login
npm run deploy
这个例子保留了 FastAPI 最常用的开发方式。继续加入 Pydantic 模型、中间件和路由拆分时，仍然按照普通 FastAPI 项目组织即可。Django 的 ASGI 入口和 Flask 的 WSGI 应用也可以采用类似思路，但具体适配器和项目启动方式应以当前 Workers 工具链版本为准。
平台绑定比“能跑框架”更重要
框架兼容解决的是 HTTP 层，而绑定决定应用能否真正利用 Cloudflare 平台。比如，可以先创建 R2 存储桶和 D1 数据库：
npx wrangler r2 bucket create edge-uploads
npx wrangler d1 create edge-app-db
然后在 wrangler.jsonc 中加入对应配置。D1 创建命令会返回真实的 database_id，需要替换下面的占位值：
{
"$schema": "node_modules/wrangler/config-schema.json",
"name": "fastapi-edge-api",
"main": "src/entry.py",
"compatibility_date": "2024-03-20",
"compatibility_flags": ["python_workers"],
"r2_buckets": [
{
"binding": "UPLOADS",
"bucket_name": "edge-uploads"
}
],
"d1_databases": [
{
"binding": "DB",
"database_name": "edge-app-db",
"database_id": "替换为-d1-命令返回的-id"
}
]
}
运行时会通过 self.env.UPLOADS 和 self.env.DB 暴露这些资源。相同的绑定模型也覆盖 Workers AI、Hyperdrive、Durable Objects、Queues 和 Workflows。它带来两个直接收益：
- 代码中不再保存长期云服务密钥，资源访问关系由部署配置声明。
- 本地、预发布和生产环境可以绑定不同资源，而不必修改业务模块。
不过，绑定名称仍然属于应用接口。建议集中封装数据访问逻辑，不要让每个路由都直接操作 self.env，否则测试和后续迁移会变得困难。
迁移前先检查运行时假设
“FastAPI、Django、Flask 能运行”不代表任意现有项目都能原封不动部署。上线前至少检查以下项目：
- 原生扩展：依赖系统动态库、特定 CPU 指令或编译型扩展的 Python 包，需要确认 Workers/Pyodide 环境是否支持。
- 本地文件系统：不要把上传文件、SQLite 数据库或生成结果长期保存在本地路径；持久数据应进入 R2、D1 或其他外部存储。
- 后台进程：依赖
subprocess、守护线程、Celery worker 或常驻进程的设计不能直接照搬，可考虑 Queues 和 Workflows。 - 数据库连接：传统 ORM 可能假设存在普通 TCP 连接和长期连接池。迁移时要评估 D1、Hyperdrive以及所用数据库驱动的兼容性。
- 全局状态：普通 Worker 实例的内存不是可靠的持久状态；需要一致性和协调能力时，应明确使用 Durable Objects。
- 依赖体积与启动成本：只保留请求路径真正需要的包，避免把数据科学工具链或大型模型一并打入简单 API。
比较稳妥的采用路径是：先迁移一个无状态、依赖较少的查询接口，再接入一个平台绑定，观察日志、延迟、异常率和依赖兼容性。确认运行模型后，再处理 ORM、后台任务和有状态工作流。
Python Workers GA 的价值，不是让边缘运行时伪装成传统服务器，而是让 Python 开发者使用熟悉的框架进入 Workers 平台。框架层的胶水代码正在消失，但运行时边界依旧存在。理解这些边界，才能把 FastAPI 或 Django 真正变成边缘应用，而不是把一台服务器的假设硬塞进 isolate。