Cloudflare Workers 正式支持 Python：哪些服务能搬走，哪些还得留在 VPS？

Cloudflare Workers 对 Python 的支持已经从长期的 preview 状态转为正式可用（GA），这件事对自建服务的个人开发者有实际影响：过去要在云端跑一个 Python 小服务，基本绕不过一台 VPS；现在一个 FastAPI 应用可以直接部署到全球边缘网络，不需要自己维护操作系统、反向代理和证书。但这并不意味着 VPS 可以立刻退租，哪些服务能搬、哪些搬不动，取决于依赖类型和运行特征。这篇把这次变更的实际内容、成本账和迁移边界讲清楚。

这次转正具体改了什么

Python Workers 并不是新产品，它从 2024 年 4 月就开放了 beta，之后长期挂着 preview 标签。之所以一直不太好用，主要卡在互操作上：Python 运行在 Pyodide（编译成 Wasm 的 CPython）里，与 JavaScript 宿主之间的数据传递需要手动做类型转换，给队列发一个字典都要先写一段 JS 胶水代码。这次转正解决的核心问题就是这层转换。

两个变化最值得关注。第一是 ASGI 与 WSGI 连接器正式可用，FastAPI、Starlette 这类 ASGI 框架用 workers.asgi 接入，Django、Flask 这类 WSGI 框架用 workers.wsgi 接入，只需要一行入口代码。连接器带来的实际好处是原本由 uvicorn、gunicorn 承担的 web server 工作转交给 Cloudflare 的网络，代码里只剩下业务逻辑，并发处理、负载均衡、反向代理这些运维对象直接消失。第二是 PyPI 依赖的部署路径打通，符合 PEP 783（PyEmscripten）规范的包可以带 Wasm 构建直接部署，纯 Python 包则可以直接使用。

成本账：省下的是哪一笔钱

对比要建立在同一计量口径上。Cloudflare Workers 的付费计划是账户级最低消费 5 美元/月，包含每月 1000 万次请求与 3000 万 CPU 毫秒；超出后请求按每百万次 0.30 美元计费，CPU 时间按每百万毫秒 0.02 美元计费。免费计划每天 10 万次请求、每次调用 10 毫秒 CPU 时间，数据处理与出口带宽不单独收费。单次调用的 CPU 时间上限为 5 分钟，默认 30 秒，定时任务和队列消费者的上限是 15 分钟。以上为官方定价页核验的数据，实际账单以控制台为准。

把两列放在一起看，结论比较清楚。一个日均请求量在几千次以内的轻量 API 或 webhook 接收端，免费计划就能覆盖，省下的是整台 VPS 的租金加上持续的运维时间。请求量上去之后，付费计划的 5 美元/月与一台常规月付 VPS 处于同一量级，此时选择更多取决于是否愿意用运维投入换取成本弹性。

这里有一个容易被忽略的计费点：CPU 时间而不是请求次数才是成本变量。Python 跑在 Wasm 编译的 CPython 上，同样的逻辑比 V8 里的 JavaScript 消耗更多 CPU，付费计划免费额度里的 3000 万 CPU 毫秒听起来宽裕，如果业务涉及大量 JSON 解析、模板渲染或加密运算，消耗速度会比预期快。稳妥的验证方式是先把一个非关键服务迁上去跑一周，在控制台观察每次调用的 CPU 时间分布，用 P50 和 P99 判断长期成本，再决定是扩大迁移范围还是退回 VPS。

能搬走的三类服务

第一类是 AI 相关的胶水代码。目前大量 AI 周边逻辑是用 Python 写的，把一个 FastAPI 接请求、LangChain 做编排、R2 存结果的流程部署上线，过去需要一台 VPS 或一套容器环境，现在整个链路可以在 Workers 上完成，不需要写 JavaScript，也不需要维护服务器。官方文档里也提供了 Django、FastAPI、Flask、LangChain 的示例工程，迁移路径是有参考的。

第二类是请求量小但要求低延迟的接口服务。Worker 部署在全球边缘节点，访客就近接入，省去了自建机房选址和线路优化的问题。对于给静态站点提供少量动态接口的场景，这类服务放在边缘比放在单台 VPS 上响应更快。

第三类是定时任务与 webhook 接收。Cron Trigger 与队列消费的单次 CPU 时间上限放宽到 15 分钟，覆盖面比默认的 30 秒宽很多，处理数据抓取、报表生成、消息中转这类周期性任务足够。这类任务恰恰是 VPS 上最需要人盯着的部分，迁移收益比较直接。

搬不走的：哪些还得留在 VPS

最大的限制来自 PHP 生态。WordPress 这类常驻应用目前没有对应的 Workers 方案，它依赖完整的文件系统语义、持久化的 PHP 进程和 MySQL，边缘运行时里没有对应物。站内此前梳理过 LNMP、Docker、宝塔与 1Panel 的建站方案对比，这些方案短期内仍然需要在 VPS 上跑。

第二类限制来自运行时本身。multiprocessing 与 threading 模块虽然能导入，但不具备实际功能；fcntl、termios、venv、pty、tty 等模块被移除或导入失败。这意味着依赖多进程模型、需要操作终端设备或动态创建虚拟环境的服务无法直接迁移。

第三类是资源特征不匹配的服务。Workers 的实例是短期、无状态的，需要常驻内存、长连接或本地文件持久化的服务，例如数据库、Redis、需要写入磁盘的爬虫、视频转码任务都不适合。可以用 Workers 做前端接入，但后端仍然要放在 VPS 或托管数据库上。

第四类是整体迁移的框架型应用。Django 在代码层面可以通过 WSGI 连接器运行，但模板、静态文件、session 存储需要改接到 R2、KV、D1 等绑定，admin 后台这类重数据库功能是否可用需要实测性能后才能判断。把一个成熟的 Django 整站搬上去，改造成本可能高于直接重写接口层。

迁移前要确认的三件事

先确认依赖包能不能用。纯 Python 包可以直接部署，带 C 扩展的包需要提供符合 PEP 783 的 Wasm 构建，否则装不上。动手前把项目依赖过一遍，重点看数据库驱动、图像处理、科学计算这几类常见的高风险依赖。

再确认状态放在哪里。Workers 本身不保存状态，session、文件上传、任务进度都要外置到 KV、R2、D1 或外部数据库。这一步决定了迁移的工作量，也决定了后续的迁移成本：绑定体系用得越深，换平台的代价越高。比较稳妥的做法是把业务逻辑放在 Worker 里，数据尽量放在可导出的存储上，保持无状态化。

最后确认网络出口行为。VPS 上可以自由配置出口 IP、设置反向代理、使用原始套接字，Workers 的运行环境在这些方面有约束。涉及固定出口 IP、特殊协议或需要直连内网的服务，先验证能否满足再动手。至于保留在 VPS 上的那部分服务，规范的做法是先做安全加固，站内整理过 VPS 到手后必做的安全配置，以及一份 VPS 新手防坑清单，可以对照检查。

结论

这次转正把 Python 服务上云的门槛从”搭建并维护一台服务器”降到”执行一条部署命令”，对以 Python 为主的个人开发者是实质性的减法。合理的做法是把 VPS 的职责收窄：把无状态、请求量可控、不需要常驻的 Python 服务迁到 Workers，把 WordPress、数据库、需要常驻或需要完整系统语义的服务留在 VPS 上。VPS 不会消失，但它会从”什么都跑”变成”只跑必须常驻的东西”，管理面越小，出故障的概率越低。留在 VPS 的那部分如果是轻量业务，可以按成本选低价档位，例如 CloudCone 这类年付方案，或 ColoCrossing 的低价机型，具体配置与实时价格以官网为准。

常见问题

Cloudflare Workers 跑 Python 要额外收费吗？

不需要，与 JavaScript Worker 同价。免费计划每天 10 万次请求、每次调用 10 毫秒 CPU 时间；付费计划账户最低消费 5 美元/月，包含每月 1000 万次请求与 3000 万 CPU 毫秒，超出部分按每百万次请求 0.30 美元、每百万 CPU 毫秒 0.02 美元计费。

FastAPI 和 Django 都能直接部署吗？

代码层面都可以。ASGI 框架（FastAPI、Starlette）使用 workers.asgi 接入，WSGI 框架（Django、Flask）使用 workers.wsgi 接入，各自只需一行入口代码。Django 的模板、静态文件与 session 需要改接 R2、KV、D1 等绑定，admin 后台建议实测性能后再决定。

哪些 Python 功能在 Workers 上不可用？

multiprocessing 与 threading 可以导入但没有实际功能；fcntl、termios、venv、pty、tty 等模块被移除或导入失败。依赖多进程模型、终端设备操作或动态创建虚拟环境的代码需要改写。

PyPI 上的包都能装吗？

纯 Python 包可以直接使用；含 C 扩展的包需要提供符合 PEP 783（PyEmscripten）规范的 Wasm 构建。迁移前建议先过一遍依赖清单，数据库驱动、图像处理、科学计算库是常见的高风险项。

免费计划够用吗？

看请求量与 CPU 消耗。每天 10 万次请求配合每次 10 毫秒 CPU 时间的额度，对日均请求几千次的轻量接口、webhook 接收端、定时任务基本够用。涉及大量 JSON 处理、模板渲染或加密运算的服务，CPU 时间会更快触及上限。

WordPress 能搬到 Workers 上吗？

目前不行。WordPress 依赖完整的 PHP 运行环境、文件系统语义与 MySQL，边缘运行时没有对应实现。这类常驻应用仍需要 VPS 或主机环境，Workers 更适合作为前端接口层与静态资源分发的补充。