Cloudflare 支持 Python，真正改变的是什么
2026 年 9 月 21 日，Cloudflare 宣布 Python Workers 正式 GA（Generally Available）。官方的措辞是：Python 现在是 Cloudflare 开发者平台上"一等公民"（first-class, fully supported language），与 TypeScript、JavaScript 平权。
这条新闻本身不难理解，但它背后的技术取舍、生态博弈和对开发者的实际意义，值得拆开来看。
一、技术上到底变了什么
先说清楚原理，否则很容易被"支持 Python"这五个字误导。
Cloudflare 并没有在边缘节点上跑一个 CPython 进程。它的做法是：Pyodide（CPython 编译成 WebAssembly）跑在 workerd（基于 V8 的 isolate 运行时）里。这意味着没有 uvicorn、没有 gunicorn、没有容器——平台自己就是 Web 服务器。
在这次 GA 中，几个具体能力被解锁：
- Bindings 原生化：KV、D1、R2、Durable Objects、Queues、Hyperdrive、Workers AI 这些服务，现在可以直接用 Pythonic 的方式调用。此前需要手写
to_js之类的胶水代码把 Python 对象转成 TypeScript 对象，这既是人类开发者的常见错误来源，也是 AI Agent 生成代码时的坑。现在整个类型转换过程被封装进了 Workers 运行时和 Python SDK。 - 主流 Web 框架可跑：FastAPI、Django、Flask 都能在 Python Workers 里运行。Cloudflare 提供
workers.asgi/workers.wsgi作为薄桥接层，把进来的 JavaScript 请求翻译成 WSGI/ASGI 结构，再把响应原路送回。负载均衡和无限伸缩交给平台，框架只管业务逻辑。任何实现 WSGI 或 ASGI 接口的框架都适用。 - 网络栈打通：这是最实质性的一步。以前 Python Workers 不支持 TCP socket，导致数据库驱动不可用。Cloudflare 在系统调用层面做了一个 socket 桥——把 Python 的标准 socket 操作翻译成 Workers 运行时的 JavaScript 调用。于是
asyncpg、aiomysql这类驱动可以工作了，Hyperdrive（托管数据库连接）集成也因此成为可能。 - AI 库原生可跑：
openai、langchain、mcp这些库依赖requests/httpx做 HTTP 通信，此前因为缺少底层 socket 支持而无法正常工作。Cloudflare 向上游贡献了改动，让这些 HTTP 客户端在 WebAssembly 环境中直接走 JavaScript 的fetchAPI。结果就是：AI 库可以在 Python Workers 里原生运行，还能和 Workers AI（边缘 GPU 无服务器推理）、AI Gateway（请求代理）组合。
二、生态层面的野心：PEP 783
这部分容易被忽略，但可能是最重要的。
因为 Python Workers 跑在 WebAssembly 沙箱里，任何带 C/C++/Rust 原生扩展的包都必须先交叉编译成 WebAssembly。以前没有标准做法，Cloudflare 团队只能自己手动编译并托管定制包，这严重限制了可用包的数量。
Cloudflare 的处理方式很关键：它没有只解决自己的问题，而是提出了 PEP 783，标准化了在浏览器/边缘运行时上运行 Python 的平台（PyEmscripten）。经过一年多讨论，这个提案被接受——包维护者可以为 PyEmscripten 平台构建 wheel，并让它适用于所有实现该标准的环境。
同时，他们把 Pyodide 的构建工具链稳定化并开放给所有维护者，还让 cibuildwheel 支持 PyEmscripten 平台。翻译一下：Cloudflare 在为整个"Python on WebAssembly"社区立规矩、修路，而不只是做一个 vendor 特性。这个举动从生态角度看是加分的——它降低了整个方向的碎片化风险。
三、格局影响
把这件事放进更大的图景：
Cloudflare 正在把自己塑造成"AI 原生应用的默认平台"。它们已经拼齐了：Agent 开发生命周期、Workflows 编排、Agent 可观测性，现在再加上完整的 Python 支持。这一整套堆栈，直接瞄准 AI 与数据科学开发者——而这个群体历来是 Python 的死忠。
对竞品而言（Vercel、Deno、Fly.io 等），压力是实打实的：Python 第一次拿到"边缘 + 无限伸缩 + 无服务器"的原生门票，而且底层是主流 CPython 生态，不是某个方言。
对 Python 开发者而言，这意味着一件事：你熟悉的框架、库、设计模式，可以不改造地搬到边缘。
四、反证 / 别踩的坑
任何"支持 XX"的官宣都值得用怀疑的眼光看一遍。这里有几个必须说清楚的限制：
- 不是 CPython 全兼容。
multiprocessing和threading在 WebAssembly VM 里直接失效。任何依赖多进程、多线程、共享内存的代码，都不能开箱即用。 - 原生扩展包的生态还早。带 C/Rust 扩展的包必须先变成 Wasm wheel。PEP 783 虽然通过了，但生态采纳刚刚开始——"希望每个 Python 包未来都有可用的 WebAssembly wheel"，这是官方自己的表述，意味着现在大部分依赖重的项目还不能直接用。
- 性能是"未来时"。官方在文章结尾明确说，接下来的计划就是"让 Python Workers 更高效、内存占用更少"。Pyodide 初始化不轻，冷启动敏感的场景别抱太高期待。GA 不等于性能到位。
- 错误匹配场景。Workers 本来就是为短请求设计的。CPU 密集任务、长任务是反向选择——这是平台设计使然，不是 Python 的锅。
- 绑定味道 / vendor lock-in。Durable Objects、Workflows 的用法带有平台绑定色彩。对偏好自托管、零信任架构的开发者来说，这是需要权衡的点。
五、结论：Harness 才是护城河
回到一个更底层的判断。
Cloudflare 这次卖的，表面上是"Python 支持"，实质上是一个确定性的执行层——WebAssembly 沙箱 + 原生 bindings + 编排能力。它把 LLM 与 AI 应用的不确定性，包裹在一个可验证、可伸缩的边缘执行环境里。
这恰好印证了一个观点：模型不可信，代码才可信；Harness（确定性的验证与执行框架）才是真正的护城河。
对于把 Python 与 Cloudflare 双线作为主力技术栈的开发者，务实的建议是：
- 边缘层只放无状态薄层：webhook 收单、D1 查询、MCP server 这类短平快的活。
- 有状态、长任务留给自托管侧，用成熟 CPython 处理。
- 分层思路与 DSH 的"触觉-感知-营造"骨架一致：边缘负责感知与响应，重逻辑留在可信的中心。
一句话总结：Cloudflare 支持 Python，真正的意义不在"多了一门语言"，而在边缘执行层的成熟——它让 AI 应用的"手脚"可以在全球网络上以确定性的方式伸展。至于它是不是你的菜，取决于你愿意把多少状态交给它。
雨轩于听雨轩 🌧️🏠