用过 Cloudflare Workers 部署 Next.js 的开发者应该都有一个共同感受：真香。全球 330 个节点，按量付费，不用管服务器。部署一个前端项目只要几分钟，体验丝滑到让人上瘾。
但如果你想在 Workers 上跑 Python？之前的体验就……挺一言难尽的。
2024 年 Cloudflare 推出了 Python Workers 的「基础支持」。听起来挺美好，实际用起来：包少得可怜，冷启动慢到让人怀疑人生，基本就是个「能跑」的状态。想用 FastAPI？想用 NumPy？想用 Pillow 处理图片？对不起，不支持，或者支持得很勉强。
所以当时我的策略是：前端用 Workers，后端还是老老实实用 VPS 或者云函数。
但最近 Cloudflare 搞了个大动作——Python Workers Redux。
这不是小修小补。是把整个 Python 体验重写了一遍。冷启动从 10 秒干到 1 秒，支持的包从一小撮变成几乎所有 Pyodide 支持的包，开发工具链也换成了 uv + pywrangler。
说白了，这次更新的意思是：Python 在 Workers 上，终于可以认真用了。
先说说之前有多难用
Cloudflare Workers 最早只支持 JavaScript 和 TypeScript。后来加了 Rust、Go 等语言的 WebAssembly 支持。2024 年才开始支持 Python，用的是 Pyodide——一个把 CPython 编译成 WebAssembly 的项目。
听起来技术很酷，但实际体验很糙。
包支持太少。 只有一小部分内置包，想装第三方库非常麻烦。用过 Vercel 或者传统云函数的人都知道，Python 生态的核心就是丰富的包。没有包支持的 Python 部署方案，基本没法用。
冷启动慢到离谱。 Serverless 的老问题了，Workers 上跑 Python 尤其严重。Pyodide 需要加载整个 Python 运行时，再加上包的导入，冷启动动辄好几秒甚至十几秒。生产环境用这个？想都别想。
工具链不友好。 开发体验很割裂，不像原生 Python 项目那样顺手。
所以 2024 年的 Python Workers，更像是一个「技术预览」，不是真正能用的产品。
Redux 版本改了什么
2025 年 12 月，Cloudflare 发布了 Python Workers Redux。这次更新解决了上面说的三个核心问题。
冷启动：从 10 秒干到 1 秒
这是最重要的改进。
Cloudflare 用了一个叫「内存快照」的技术。原理其实不复杂：
- 部署的时候： 执行你的 Worker 代码的顶层作用域（包括所有 import），然后把内存状态拍个快照存下来
- 运行的时候： 直接从快照恢复，不需要重新执行 Python 启动和包导入
这招太狠了。
Python 启动慢，主要慢在两个地方：运行时初始化和包导入。内存快照直接跳过这两步，冷启动时间一下子就下来了。
来看实测数据。测试场景是导入 httpx、FastAPI、Pydantic 三个常用包：
| |
|---|
| Cloudflare Python Workers | |
| |
| |
比 AWS Lambda 快 2.4 倍，比 Cloud Run 快 3 倍。
更爽的是，这个快照功能是自动的、免费的。不像 AWS 的 SnapStart，还要额外配置，还要额外付费。
包支持：终于能用常见的包了
现在 Python Workers 支持「任何 Pyodide 支持的包」。这意味着：
- 很多依赖 C 扩展的包，比如 NumPy、Pandas、Pillow
常用的基本都能用了：
你在本地 Python 项目里用的包，大概率在 Workers 上也能跑。这一点和之前比，简直是天壤之别。
开发体验：uv + pywrangler
Cloudflare 围绕 uv（最近很火的 Python 包管理器）搭建了新的工具链。核心工具叫 pywrangler。
工作流程变得很简单：
# 安装 pywrangler
uv tool install workers-py
# 用模板创建项目
pywrangler init --template https://github.com/cloudflare/python-workers-examples/03-fastapi
# 本地开发
pywrangler dev
# 部署
pywrangler deploy
依赖管理就是标准的 pyproject.toml。pywrangler 会自动读取依赖、打包、部署。
还支持类型提示生成。跑一下 pywrangler types，就能生成和 Pyodide 兼容的类型定义，配合 mypy 或 Pylance 用。
能干什么？几个实用场景
技术细节说完了，聊聊实际能用来干什么。
全球部署 FastAPI 服务
这是最直接的用法。一个简单的 FastAPI 应用：
from fastapi import FastAPI
from workers import WorkerEntrypoint
import asgi
app = FastAPI()
@app.get("/")
async def root():
return {"message": "This is FastAPI on Workers"}
class Default(WorkerEntrypoint):
async def fetch(self, request):
return await asgi.fetch(app, request.js_object, self.env)
pywrangler deploy 一下，就部署到全球 330 个节点了。
不用配 Nginx，不用管负载均衡，不用担心某个地区的用户访问慢。这种体验，用过 Vercel 部署前端的人应该很熟悉。现在 Python 也能这么玩了。
边缘图片处理
用 Pillow 在边缘处理图片。用户上传图片，你在最近的边缘节点做裁剪、压缩、加水印，然后返回。延迟比集中式服务器低很多。
Webhook 处理
接收第三方服务的 Webhook，做数据处理和转发。Python 写这种逻辑比 JavaScript 舒服多了，尤其是涉及到数据处理的时候。
用 Durable Objects 做有状态服务
Python Workers 现在支持 Durable Objects。可以做 WebSocket 长连接、聊天室、协作编辑这类需要状态的应用。
免费额度和成本
这是独立开发者最关心的问题。
免费版
个人项目、小工具、MVP 验证，免费额度基本够用。
付费版（$5/月起）
- 超出部分：$0.30/百万请求，$0.02/百万 CPU 毫秒
对比 AWS Lambda 和 Vercel，这个价格算便宜的。Cloudflare 的定价策略一直比较透明，不容易踩坑。
还有什么限制？
说完优点，也得说说坑。Python Workers 不是万能的。
包支持还是有边界
虽然说「支持所有 Pyodide 支持的包」，但 Pyodide 本身也有限制。一些依赖特定系统调用或者复杂 C 扩展的包可能跑不了。
用之前最好先查一下 Pyodide 的兼容性列表。
原生 TCP 和同步 WebSocket 还不支持
如果你需要直接操作 TCP 套接字，或者用同步的 WebSocket 客户端，目前还做不到。这些在 roadmap 上，但还没实现。
执行时间和内存限制
免费版每次请求最多 10 毫秒 CPU 时间，内存 128 MB。复杂计算或者大数据处理，肯定不够用。付费版限制宽松一些，但仍然不适合跑重型任务。
调试体验还在完善
本地开发和调试的体验，比 JavaScript Workers 还是差一点。遇到问题排查起来可能会麻烦一些。
值不值得用？
我的判断是这样的。
现在就可以试试的场景：
可以再观望的场景：
不适合的场景：
- 对冷启动延迟零容忍的场景（1 秒已经很快，但毕竟还是有冷启动）
最后
从 2024 年的「勉强能跑」到 2025 年的「可以认真用」，Cloudflare 在 Python Workers 上的进步是实打实的。
对我来说，以后一些轻量的 Python API 服务，可能会直接扔到 Workers 上，不用再去折腾 VPS 或者传统云函数了。全球部署、按量付费、不用管服务器，这个组合确实香。
当然，它不是银弹。复杂项目还是得根据实际需求选型。
但作为技术栈里的一个选项，Python Workers 现在终于值得认真考虑了。
参考链接：
- Cloudflare 官方博客：https://blog.cloudflare.com/python-workers-advancements/
- Python Workers 文档：https://developers.cloudflare.com/workers/languages/python/
- 示例代码：https://github.com/cloudflare/python-workers-examples
10个月宝宝每天需要喝多少奶粉？
