Cloudflare Python Workers GA：依托 Pyodide 与 PEP 783 标准打通 WebAssembly 生态，支持主流框架但冷启动仍存疑

Cloudflare 正式发布 Python Workers，支持主流 Web 框架及全栈服务绑定，依托 Pyodide 运行时。关键突破在于推动 PEP 783 成为 WebAssembly 环境下 Python 包的打包标准，统一交叉编译流程；加固 Pyodide 构建工具链；集成 cibuildwheel 对 PyEmscripten 的原生支持。

PEP 783 成为首个面向浏览器内 Python 的官方打包标准

Pyodide 工具链强化使社区可自主构建 WebAssembly wheel

cibuildwheel 原生支持降低 WASM 包维护门槛

适合云原生工程师、Python 后端开发者、WebAssembly 工具链维护者阅读

Cloudflare 最近正式推出了 Python Workers，距离首个预览版发布已经过去两年。如今，Python 已经与 JavaScript 和 TypeScript 一起成为开发者平台的重要组成部分。它提供了与 Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues 和 Workflows 的绑定，并且支持 FastAPI、Django 和 Flask。

有三项工程成果促成了这次正式发布，其中两项来自 Cloudflare 之外。

首先是一个打包标准。Python Workers 在 Pyodide 上运行，因此，任何带有 C、C++ 或 Rust 扩展的包都必须交叉编译为 WebAssembly，而之前没有标准的方法来实现这一点。Cloudflare 曾经自行编译并托管这些包，但这限制了可用包的数量。该公司提出了 PEP 783，旨在为浏览器内的 Python 运行时平台 PyEmscripten 制定标准。该提案在一年多后获得通过。Cloudflare 还加固了 Pyodide 构建工具链，并在 cibuildwheel 中添加了对 PyEmscripten 的支持，从而使维护者能够构建自己的 wheel 包。

第二项是套接字桥接。aiomysql 和 asyncpg 等驱动程序使用了标准库中的 socket 模块。该模块会发起 POSIX 系统调用，而这些调用在 WebAssembly 沙箱中只是桩函数。Cloudflare 通过 Workers 的 connect API 实现了这些调用。转换是在系统调用层进行的，因此，驱动程序无需做任何修改，这也正是 Hyperdrive 集成能够正常运行的原因。

第三项是针对 HTTP 客户端的上游贡献。现在，包括 requests 和 httpx 在内的库会在 WebAssembly 环境中通过 JavaScript 的 fetch API 进行路由，这使得 OpenAI、LangChain 和 MCP 均能够在 Worker 中运行。

绑定本身也变得更具 Python 风格了。此前，将字典发送到队列需要通过 to_js 并使用 dict 转换器进行转换；现在，类型转换在运行时和 SDK 内部完成。Web 框架通过连接器而非服务器实现，workers.asgi 和 workers.wsgi 会将传入的 JavaScript 请求转换为 WSGI 和 ASGI 应用程序所期望的结构，其理由是该平台本身就是 Web 服务器。

社区对此的反应两极分化，争议焦点与其说是这些新特性本身，不如说是它们背后的实现机制。

第三项引发的反响最激烈。作为 urllib3 的维护者，illia-v 在 Hacker News 上发文解释道，他的项目合并了多项重大的贡献，包括添加对 Pyodide 和 Emscripten 的支持，以及后来的 JSPI 支持。正是这些贡献使该功能得以在 requests 中实现。他指出，资金流向了实现该功能的贡献者，而非最终负责维护该项目的维护者：

资助项目的上游贡献与资助上游维护者之间存在着本质性的区别。

其影响在 urllib3 自身的立场中有所体现。在该项目中，Emscripten 后端仍然处于实验阶段，而且被明确排除在项目的安全策略之外。他指出了 CVE-2025-50182 这一漏洞——当请求通过 fetch 进行路由时，urllib3 的重定向控制机制未能按预期发挥作用——并提醒说，可能还存在其他不少此类的差异，因为浏览器的网络语义与常规的 urllib3 后端有所不同。

冷启动引发的是数据层面的关注，而非用户的抱怨。Wasmer（一家销售竞争性 WebAssembly 平台的公司）创始人 Syrus Akbary 重提了他在最初发布其产品时提出的担忧：

以他们目前的架构，要实现 <100ms 的启动时间将相当困难。

他表示，根据该公司今年早些时候发布的一项基准测试，在 Wasmer Edge 上，一个最简单的 Python 应用程序的启动时间约为 60 毫秒，而在 Cloudflare Workers 上则约为 900 毫秒，并询问了当前使用和不使用原生包时的 p50 和 p95 数据。

该博文的作者之一 Dominik Picheta 代表 Cloudflare 方面回答道：

我们的内存快照实现已经显著改善了冷启动性能。

他补充道，分片技术可以减少冷启动的发生频率，并提到了之前一篇包含具体数据的文章。Akbary 在后续评论中指出，这篇文章中报道的启动时间约为 1.027 秒，并问在那之后是否重新测量过。

Akbary 提出的另一项异议是关于版本耦合，即受限于 workerd 所嵌入的 Python 和 Pyodide 版本。Picheta 回答说，兼容性标志可以是 Python 3.12、3.13 或 3.14，同时指出，旧版本对应的是功能更少的 Pyodide 旧版本，JSPI 也不在其中。Akbary 认为这证实了该问题，因为该标志也会影响 workerd。

评论者 dangoodmanUT 单独提出了一个与内存相关的担忧，但他尚未对此进行测试：

这可能会使工作进程的内存分配增加数十 MB。

讨论解决的是技术问题，而非商业问题。Akbary 认为，通过打补丁让 Python 的事件循环使用 JavaScript 循环会导致不兼容，因为两者在协程的执行时机上存在差异。该博文的另一位作者、Pyodide 贡献者 Hood Chatham 回复道：

使用 WebLoop 时，Python 协程仍然保持惰性。

他补充道，Python 事件循环所需的基本函数是 call_later，它与 setTimeout 完美对应；而必须使用 JavaScript 循环，是因为运行时中的 I/O 事件是在那里发生的。如果再添加一个循环，就会阻塞这些事件。

同一条讨论帖中还包含了能回应“资金支持不足”这类批评的说明。Simon Willison 建议 Cloudflare 向 Pyodide 提供资金支持。Picheta 指出，另一位作者 Gyeongjae Choi 是 Pyodide 的核心开发者，而 Chatham 则是 Cloudflare 聘请的 Pyodide 贡献者。公告中提到的三人中有两人负责维护该运行时所依赖的项目。

如果这些反响具有代表性，那么 GA 标签带来的影响可能不如其背后的工程实现那么显著。该打包标准消除了对单一供应商编译 wheel 包的依赖，而系统调用桥接机制则使得现有的驱动程序无需修改即可正常工作。目前尚待明确的是，未来将由谁来维护上游组件，以及运行时在启动时和内存占用方面的开销究竟如何。

Cloudflare 已经在 python-workers-examples 仓库中发布了产环境应用模式，从其开发文档中现在也已经可以看出，Python 已经与 JavaScript 和 TypeScript 一起出现在各产品中。关于性能，该公司仅表示计划提高 Python Workers 的性能并优化其内存效率。

原文链接：https://www.infoq.com/news/2026/09/cloudflare-python-workers-ga/