Python Workers 现已正式可用。开发者可以在 Cloudflare Workers 运行时中原生使用 Python Web 框架和 AI 编排库，并直接连接 D1、R2、Workers AI 等服务，不再需要额外编写一层 JavaScript 胶水代码。
这项变化真正有价值的地方，不只是“边缘环境也能运行 Python”，而是 Python 应用从请求处理、数据存储到模型调用都可以留在同一种语言和同一套部署模型中。
从双语言适配层回到单一 Python 项目
过去，把 Python 业务逻辑放进以 JavaScript 为主的边缘运行时，常见做法是让 JavaScript 接收请求，再调用 Python 服务或转换数据。结果是一个简单接口也可能同时维护两套依赖、错误处理和类型约定。
Python Workers 将入口直接放在 Python 中。典型请求链路可以收敛为：
HTTP Request
↓
Python Worker
├── D1：查询结构化数据
├── R2：读写对象
└── Workers AI：执行模型推理
↓
HTTP Response
这对以下项目尤其有吸引力：
- 已经使用 Python Web 框架编写 API 的团队；
- 依赖 Python AI 编排库、提示词流水线或数据处理代码的应用；
- 希望把轻量 API 部署到边缘，但不想维护 JavaScript 适配层的项目；
- 需要同时访问数据库、对象存储和托管模型的服务。
“原生运行”并不意味着完整复制一台传统 Python 服务器。Workers 仍然属于受管理的边缘运行时，应用应围绕请求处理、绑定资源和短生命周期任务设计，而不是假设存在永久进程或可长期写入的本地磁盘。
一个最小 Python Worker
下面是一个可以作为项目入口改造的最小示例。它使用 Workers 提供的 Python 入口和响应对象，不需要 JavaScript 文件：
# src/entry.py
import json
from workers import Response, WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
payload = {
"message": "Hello from Python Workers",
"method": request.method,
"url": request.url,
}
return Response(
json.dumps(payload),
headers={"content-type": "application/json; charset=utf-8"},
)
可以使用 Cloudflare 的项目生成器创建 Worker，再把生成的 Python 入口替换为上面的代码：
npm create cloudflare@latest -- my-python-worker
cd my-python-worker
npx wrangler dev
在生成器中选择 Python Worker 模板。启动本地开发服务器后，可以用 curl 验证：
curl http://localhost:8787/
预期会得到类似响应：
{
"message": "Hello from Python Workers",
"method": "GET",
"url": "http://localhost:8787/"
}
确认无误后部署：
npx wrangler deploy
项目生成器和配置字段可能随 Wrangler 版本调整，因此应优先保留当前 Python 模板生成的兼容日期、运行时标志和入口配置，只替换业务代码。
用绑定连接 D1、R2 与 Workers AI
Python Workers 可以直接使用 Cloudflare 生态中的资源绑定。下面是一份可供改造的 wrangler.toml 示例；其中数据库 ID、数据库名称和存储桶名称必须替换成自己的资源信息：
name = "python-edge-service"
main = "src/entry.py"
compatibility_date = "2025-01-01"
[[d1_databases]]
binding = "DB"
database_name = "app-db"
database_id = "REPLACE_WITH_YOUR_D1_DATABASE_ID"
[[r2_buckets]]
binding = "BUCKET"
bucket_name = "app-assets"
[ai]
binding = "AI"
绑定名称决定 Python 代码如何访问资源：
# 在 WorkerEntrypoint 实例中
self.env.DB # D1 数据库
self.env.BUCKET # R2 存储桶
self.env.AI # Workers AI
这样可以让一个请求在同一个 Python 处理器中完成多步工作。例如：
- 从 D1 读取用户配置或会话元数据；
- 从 R2 获取文档、图片或其他对象；
- 将整理后的输入交给 Workers AI；
- 用 Python 生成最终 HTTP 响应。
来源摘要没有限定具体框架、模型或绑定方法签名，因此接入业务代码时，应以当前 Python Workers 模板和对应服务的 SDK 接口为准。稳妥的方式是先分别验证 DB、BUCKET 和 AI 绑定，再将它们组合进完整请求链路，避免一次性调试多个权限和配置问题。
迁移前要检查的边界
Python Workers 降低了语言切换成本，但它不等同于把现有 Flask、Django 或 FastAPI 服务原封不动搬到传统虚拟机。迁移时建议检查：
- 依赖兼容性：确认第三方包能否在 Workers Python 运行环境中使用，特别是带原生扩展的包；
- 状态管理：不要依赖进程内全局变量保存持久状态，应使用 D1、R2 或其他适合的外部服务；
- 文件系统假设：把本地文件读写改造成对象存储或构建期资源；
- 执行模型：避免无限循环、常驻后台线程和长期阻塞任务；
- 超时与资源限制：AI 编排链越长，越需要控制模型调用次数、上下文长度和失败重试；
- 可观测性：为数据库查询、对象读取和模型调用分别记录耗时与错误类型。
推荐从一个边界清晰的接口开始，例如健康检查、文本摘要、文档分类或只读数据查询。先验证 Python 入口、资源绑定和部署流程，再逐步迁移复杂框架与 AI 工作流。对于以 Python 为主的团队，这种渐进式采用方式通常比一次性重写整个服务更安全，也更容易衡量边缘部署带来的实际收益。