Cloudflare Python Workers 正式 GA:Python 成为 Workers 平台一等语言
译注:本文翻译自 Cloudflare 官方博客,原文标题为《Python Workers are now generally available》,发布于 2026 年 9 月 21 日。原文链接见文末。为便于中文开发者阅读,正文在忠实原文的基础上进行了编辑整理。
Cloudflare 在两年前推出了 Python Workers,让开发者可以在 Workers 运行时中运行 Python 应用。其目标是让用 Python 编写 Workers 像用 TypeScript 一样简单,并让 Python 的包与框架生态“开箱即用”。如今,Python Workers 正式进入通用可用(GA)阶段。
GA 意味着什么
GA 意味着 Python 现在是 Cloudflare 开发者平台上的一等、完全受支持的语言。开发者可以把自己熟悉的 Python 代码、库和设计模式带入 Workers,并无缝对接 Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows 以及 Cloudflare 平台的其余部分。同时,也可以在 Python Workers 中运行 FastAPI、Django、Flask 等流行框架,甚至可以通过 Dynamic Workers 在一个 Worker 内部创建另一个 Python Worker。
from fastapi import FastAPI, Request
from workers import asgi, WorkerEntrypoint
app = FastAPI()
@app.get("/")
async def root(request: Request):
env = request.scope["env"]
return await env.AI.run(
"@cf/openai/gpt-oss-120b",
{
"instructions": "You are a friendly assistant.",
"input": "What is the origin of the phrase Hello, World?",
},
)
Default = asgi.entrypoint(app)背后的历程
把 Python 带到 Cloudflare Workers 是一个自然的选择。由于 Workers 自 2018 年起就支持 WebAssembly,这为运行编译为 Wasm 的 Python 解释器提供了理想环境。借助 Pyodide,团队得以快速在 Workers 中支持大量 Python 应用。目标是在让 Python 应用无限扩展的同时,保持与其他环境一致的开发体验与性能。今天公布的能力,正是这一多年努力的成果。
Python 成为 Workers 运行时的一等语言
Python Workers 现在原生支持 Cloudflare 开发者平台的各类绑定。此前,在 Python Workers 中使用这些绑定,需要在 RPC 边界显式地把 Python 对象转换为 TypeScript 对象。例如,向 Cloudflare Queue 发送一个 Python 字典,需要如下胶水代码:
from pyodide.ffi import to_js
import js
self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))这要求 Python 开发者在编写 Workers 时始终留意 JavaScript 环境与代码,也是人类和 AI 代理常见的错误来源。为此,团队把整个类型转换过程封装进 Workers 运行时和 Python SDK,让开发者可以用 Python 风格使用所有 Cloudflare 绑定,而无需编写任何 JavaScript 代码:
self.env.QUEUE.send({"key": "value"})Web 框架:FastAPI、Django 与 Flask
现在可以在 Python Workers 中运行 FastAPI、Django、Flask 等框架来构建 API 服务。团队实现了内置连接器,方便把 Web 应用接入 Python Workers。以一个简单的 FastAPI 应用为例:
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
async def root():
message = "Hello, world!"
return {"message": message}在原生环境中,通常会使用 uvicorn 之类的 Web 服务器来运行:
$ uvicorn main:app在 Python Workers 中,只需加入以下代码,即可用官方提供的 workers.asgi 包运行同一应用:
from workers import asgi
class Default(WorkerEntrypoint):
async def fetch(self, request):
return await asgi.fetch(app, request, self.env)
# 或者等价写法
Default = asgi.entrypoint(app)类似地,可以用 workers.wsgi 包运行 Django 等同步 Web 应用:
from workers import WorkerEntrypoint, wsgi
from your_django_app.wsgi import app
Default = wsgi.entrypoint(app)其原理在于:Python 有 Web Server Gateway Interface(WSGI)及其现代异步版本 ASGI 这一标准约定,使应用与服务器解耦。传统部署中,Uvicorn、Gunicorn 等服务器负责处理并发连接与线程以扩展流量,而 FastAPI 等框架专注应用逻辑。在 Cloudflare Workers 中,Workers 平台本身就是 Web 服务器,全球网络已经处理了负载均衡与无限扩展,因此无需在 Python Workers 内再运行服务器。workers.asgi 与 workers.wsgi 连接器充当轻量、优化的桥梁,把传入的原生 JavaScript 请求转换为 Python 应用期望的 WSGI/ASGI 结构,并以极低开销把响应回传。这样,开发者既能用喜欢的框架组织代码,又能让 Workers 平台在全球即时扩展 API,而无需配置服务器。这些连接器不仅适用于 FastAPI、Django、Flask,也适用于任何使用 WSGI 或 ASGI 接口的 Python Web 框架。
通过 Hyperdrive 使用 PostgreSQL 与 MySQL
如果使用 PostgreSQL 或 MySQL 等关系型数据库构建 Python 应用,现在可以在 Python Workers 中集成 Hyperdrive。此前 Python Workers 不支持 TCP socket,导致数据库驱动不可用。原因在于 WebAssembly 的运作方式:aiomysql、asyncpg 等驱动依赖标准库的 socket 模块建立连接,而在标准环境中该模块会向操作系统发起 POSIX 系统调用;在 WebAssembly 沙箱内,这些网络系统调用通常是必然失败的桩实现,任何打开标准 socket 的尝试都会立即失败。
为解决这一问题,团队使用 Workers 的 connect API 实现了 socket 系统调用。当数据库驱动尝试打开 TCP 连接时,会经过自定义的 socket 系统调用实现,把打开连接、读取字节等标准 Python socket 操作转换为 Workers 运行时对应的 JavaScript 调用。由于转换发生在系统调用层,数据库驱动完全无需感知底层实现。正是这一 socket 桥接让 Hyperdrive 集成成为可能。
在 Python Workers 中使用 Hyperdrive,首先通过 Hyperdrive 连接数据库,并在 Wrangler 配置中设置绑定:
"hyperdrive": [
{
"binding": "HYPERDRIVE_MYSQL",
"id": "<example id: 57b7076f58be42419276f058a8968187>",
}
]然后使用熟悉的数据库驱动连接 Hyperdrive:
import aiomysql
from workers import WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
hd = self.env.HYPERDRIVE_MYSQL
conn = await aiomysql.connect(
host=hd.host,
port=int(hd.port),
user=hd.user,
password=hd.password,
db=hd.database,
ssl=None,
)
cur = await conn.cursor()
await cur.execute("SELECT username FROM user")
r = await cur.fetchall()
await cur.close()
conn.close()扩展 WebAssembly 包生态
由于 Python Workers 运行在 WebAssembly 沙箱中,任何带有原生 C/C++/Rust 扩展的包都必须交叉编译为 WebAssembly 才能运行。此前并没有把 Python 包交叉编译到 WebAssembly 的标准方式,团队只能手动编译并托管自定义的 WebAssembly 包,这极大限制了可用包的数量。
团队希望改变这一状况,同时不希望只构建仅适用于 Python Workers 的包,因为那样对社区没有益处。由于 Python Workers 构建在 Pyodide 之上,团队希望生态的演进能惠及 Pyodide 以及整个 Python-on-WebAssembly 社区。为此,他们提出了 PEP 783,为在浏览器运行时中运行 Python 定义了一个名为 PyEmscripten 的平台标准。经过一年多的讨论与完善,该提案被接受,使包维护者可以为 PyEmscripten 平台构建并发布包,并在所有实现该平台的环境中可用。
团队还稳定了既有的 Pyodide 构建工具链,使其对所有包维护者可用,方便为 PyEmscripten 平台构建包;同时为 cibuildwheel 增加了 PyEmscripten 平台支持,便于更多人采用。尽管生态仍在采纳这一标准,团队希望未来每个 Python 包都能有可在 WebAssembly 中使用的 wheel。他们也在与主要包维护者积极合作添加 PyEmscripten 构建。如果遇到尚未支持的包,可以在 Discord 或 GitHub 上反馈。
用 Python 构建 AI 代理与流水线
庞大的数据科学与机器学习包生态,使 Python 成为构建智能代理和 AI 流水线的自然选择。但把这些带到 Python Workers 曾面临挑战:openai、langchain 等库依赖 requests 或 httpx 等 HTTP 客户端与外部 API 通信,而由于缺少底层支持(原文在此处截断),这一集成此前难以实现。随着本次 GA 的推进,相关能力已逐步补齐,开发者可以在 Python Workers 中更完整地构建 AI 应用。