拓冰建站拓冰建站
首页 / 资讯中心 / 正文

Cloudflare Docs 深度解析:Python Workers 的 `python_no_global_handlers` 兼容性标志与入口类(Entrypoint Class)机制

Cloudflare Docs 深度解析Python Workers 的python_no_global_handlers兼容性标志与入口类Entrypoint Class机制【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docspython_no_global_handlers是 Cloudflare 在 2025 年 8 月 14 日随 Python Workers 处理器结构变更一同引入的兼容性标志。本指南以该标志为主线完整解析 Python Workers 从模块级全局处理器到默认入口类的演进、新旧两种写法的差异、wrangler.jsonc中的配置方法以及这一变更背后的运行时原理。读完本文你将掌握如何用新的WorkerEntrypoint入口类编写fetch/scheduled等处理器何时需要显式开启或关闭python_no_global_handlers以及该标志在 Cloudflare Docs 仓库中从声明兼容性标志文档到校验配置 Schema再到使用示例变更日志的完整落地链路。一、标志概述它到底做了什么python_no_global_handlers是 Cloudflare Docs 仓库中维护的众多兼容性标志Compatibility Flags之一其官方定义位于 src/content/compatibility-flags/python-no-global-handlers.mdWhen thepython_no_global_handlersflag is set, Python Workers will disable the global handlers and enforce their use via default entrypoint classes.翻译当设置python_no_global_handlers标志时Python Workers 将禁用全局处理器global handlers并强制通过默认入口类default entrypoint classes来使用处理器。从声明文档的 Frontmatter 中可以提取出该标志的关键元数据字段值含义nameDisable global handlers for Python Workers标志的展示名称enable_date2025-08-14该行为在 2025-08-14 起随兼容性日期默认生效sort_date2025-08-14列表排序日期enable_flagpython_no_global_handlers显式开启新行为时使用的标志名disable_flagdisable_python_no_global_handlers需要回退到旧行为全局处理器时使用的标志名需要特别注意的是该文档头部还包含一组构建控制元数据_build: publishResources: false / render: never / list: never表明这类兼容性标志文档是纯数据源不会被渲染为独立页面而是由构建系统消费、并自动归并到兼容性标志总览中。标志在仓库中的数据结构仓库用 Zod Schema 对这类标志文档做了运行时校验见 src/schemas/compatibility-flags.tsexport const compatibilityFlagsSchema z.object({ name: z.string(), enable_date: z.string().optional().nullable(), enable_flag: z.string().nullable(), disable_flag: z.string().optional().nullable(), sort_date: z.string(), experimental: z.boolean().optional(), });从中可以看到每一个兼容性标志文档的标准字段模型name、enable_date可选、enable_flag、disable_flag可选、sort_date以及可选的experimental布尔标记。这解释了为什么每个标志通常都成对提供开启与关闭两个 flag 名称——enable_flag与disable_flag是 Schema 中的一等公民允许开发者在新旧行为之间随时切换。二、背景从全局处理器到入口类的结构变更要理解这个标志必须回到同一天发布的官方变更日志 src/content/changelog/workers/2025-08-14-new-python-handlers.mdxWe are changing how Python Workers are structured by default. Previously, handlers were defined at the top-level of a module ason_fetch,on_scheduled, etc. methods, but now they live in an entrypoint class.即旧写法是在模块顶层直接定义on_fetch、on_scheduled等全局处理器函数新写法是把它们收敛进一个入口类entrypoint class中。默认行为在 2025-08-14 之后就是新写法而python_no_global_handlers标志只是把这个默认行为显式化——设置它即声明我不再用全局处理器请强制校验入口类写法。新旧写法对比变更日志给出了新的 fetch 处理器标准写法from workers import Response, WorkerEntrypoint class Default(WorkerEntrypoint): async def fetch(self, request): return Response(Hello World!)这段代码的要点WorkerEntrypoint和Response均从workersSDK 模块导入类名必须为Default这是 Python Workers 约定的默认入口类继承WorkerEntrypoint后通过实现async def fetch(self, request)来处理入站请求。对照旧写法则是把on_fetch直接写在模块顶层# 旧写法全局处理器 async def on_fetch(request, env, ctx): return Response(Hello World!)两种写法实现的功能一致但新写法把所有处理器封装在类的命名空间内与 JavaScript Workers 中export default { fetch() {...} }的入口对象心智模型对齐也让self.env等实例级状态详见下文第四节有了自然的挂载点。三、如何配置该标志wrangler 配置文件实战方式一依赖兼容性日期推荐零配置由于enable_date为 2025-08-14当你的 Worker 的compatibility_date设置在该日期或之后时新行为自动生效无需在compatibility_flags中显式列出python_no_global_handlers。一个标准的 Python Worker 配置如下出自 Python Workers 基础文档{ $schema: ./node_modules/wrangler/config-schema.json, name: hello-python-worker, main: src/entry.py, compatibility_flags: [ python_workers ], compatibility_date: $today, vars: { API_HOST: example.com } }注意其中compatibility_date使用占位符$today构建时会被替换为实际日期而python_workers标志是 Python Workers 处于 open beta 期间必须添加的另一个标志详见 Python Workers 索引文档 中的 beta 提示。此时由于日期已晚于 2025-08-14python_no_global_handlers隐含生效。方式二显式声明新行为如果你想在不依赖日期的情况下明确声明使用入口类写法可以在wrangler.jsonc的compatibility_flags数组中显式加入python_no_global_handlers{ compatibility_flags: [ python_no_global_handlers ] }方式三回退旧行为关键逃生通道这是本标志最有实战价值的用途。如果你的代码仍在使用on_fetch/on_scheduled这类模块级全局处理器或者你在维护一个尚未迁移的历史 Worker则需要显式关闭新行为。变更日志 2025-08-14-new-python-handlers.mdx 明确给出了操作方式To keep using the old-style handlers, you can specify thedisable_python_no_global_handlerscompatibility flag in your wrangler file:{ compatibility_flags: [ disable_python_no_global_handlers ] }三种方式的选择建议新项目直接采用Default(WorkerEntrypoint)入口类写法保持compatibility_date在 2025-08-14 之后无需任何额外标志迁移中的项目若代码尚未改完先通过disable_python_no_global_handlers维持旧行为平滑过渡后再移除该标志并迁移到入口类希望提前验证新行为即使compatibility_date早于 2025-08-14也可以显式添加python_no_global_handlers提前体验。四、入口类的完整能力不止 fetch新结构的价值在于Default(WorkerEntrypoint)不只是换了个写法它还获得了与 JavaScript Worker 对齐的完整处理器能力与实例状态。1. 处理 Cron 定时任务scheduled调度处理器同样收敛进入口类。仓库中 Scheduled Handler 文档 的 Python 示例即为from workers import WorkerEntrypoint class Default(WorkerEntrypoint): async def scheduled(self, controller, env, ctx): ...当 Worker 通过 Cron Trigger 被调用时运行时将调用该scheduled方法。本地开发时可以用下面的命令触发并验证curl http://localhost:8787/cdn-cgi/local/scheduled?formatjson2. 访问环境变量与绑定self.envWorkerEntrypoint上内置了env属性可用于访问环境变量、Secrets 以及各类 Bindings。示例出自 basics.mdxfrom workers import WorkerEntrypoint, Response class Default(WorkerEntrypoint): async def fetch(self, request): return Response(self.env.API_HOST)这里API_HOST即配置文件中vars块声明的环境变量见第三节的wrangler.jsonc示例。3. 返回 JSON 响应使用Response.json()可以直接序列化 Python 字典from workers import WorkerEntrypoint, Response class Default(WorkerEntrypoint): async def fetch(self, request): data {message: Hello, status: ok} return Response.json(data)4. 处理请求体request参数是通过 FFIForeign Function Interface暴露的 JavaScriptRequest对象可直接在 Python 中await其异步方法from workers import WorkerEntrypoint, Response from hello import hello class Default(WorkerEntrypoint): async def fetch(self, request): body await request.json() name body[name] return Response(hello(name))配合本地开发服务可用 curl 验证curl --header Content-Type: application/json \ --request POST \ --data {name: Python} http://localhost:8787预期输出为Hello, Python!。5. Web 框架的一等公民wsgi / asgi entrypoint入口类机制还为 Django、FlaskWSGI和 FastAPI、StarletteASGI等框架的接入铺平了道路。仓库变更日志 2026-09-02-python-workers-web-framework-support.mdx 显示from workers import wsgi from django.core.wsgi import get_wsgi_application app get_wsgi_application() Default wsgi.entrypoint(app)该日志明确指出wsgi.entrypoint等价于创建一个WorkerEntrypoint类并使用wsgi.fetch方法也就是说——新的入口类结构正是 Python Workers 支持主流 Web 框架的基石。如果你需要更细粒度的控制也可以手写入口类from workers import wsgi, WorkerEntrypoint class Default(WorkerEntrypoint): async def fetch(self, request): return await wsgi.fetch(app, request, self.env)五、运行时原理入口类如何被执行理解了标志和写法之后再看运行时层面。Python Workers 的代码由 Pyodide编译为 WebAssembly 的 CPython直接在 V8 isolate 中解释执行详见 How Python Workers Work。该文档披露的本地开发流程为根据compatibility_date确定所需的 Pyodide 版本依据pyproject.toml安装所需包为 Worker 创建新的 V8 isolate 并自动注入 Pyodide用 Pyodide 执行你的 Python 代码。部署流程则有冷启动优化部署时 Cloudflare 会执行 Worker 入口模块及其顶层 import 的所有内容然后对 Worker 的 WebAssembly 线性内存做快照把昂贵的初始化工作从运行时提前到部署时完成。这意味着class Default(WorkerEntrypoint)这个类的定义与导入工作在部署阶段就被固化进快照请求到达时直接以快照引导显著缩短冷启动时间。这也解释了为什么入口类而非模块级函数成为新的标准类定义提供了清晰的模块化边界使运行时可以在部署阶段一次性完成入口模块的解析、导入与初始化为快照机制提供稳定且可预测的执行起点。六、关联生态其他兼容性标志的启示python_no_global_handlers不是仓库中唯一的标志理解它的同时可以参考同构案例以把握 Cloudflare 兼容性机制的通用模式。例如 enable-ctx-exports.md 定义了enable_ctx_exports禁用名为disable_ctx_exports标志用于开启ctx.exportsAPI——自动为同 Worker 内的WorkerEntrypoint和 Durable Object 命名空间生成 loopback bindings。它同样遵循enable_flagdisable_flag成对、enable_date日期门槛的结构且在 变更日志 2025-09-26-ctx-exports.md 中有对应的 JS 使用示例。这套日期自动生效 显式标志控制的机制保证了 Cloudflare 既能持续推进行为演进又不破坏线上运行的应用——旧版本 Worker 不会被强制中断而是通过disable_*标志获得永久的逃生通道。python_no_global_handlers正是这一治理思路在 Python Workers 上的体现。七、总结与迁移建议围绕python_no_global_handlers可以总结出以下要点关注点结论核心行为禁用模块级全局处理器on_fetch等强制Default(WorkerEntrypoint)入口类生效日期2025-08-14compatibility_date晚于此即默认生效显式开启compatibility_flags中加入python_no_global_handlers显式关闭compatibility_flags中加入disable_python_no_global_handlers数据校验字段结构由 src/schemas/compatibility-flags.ts 的 Zod Schema 约束迁移建议如果你维护的是 2025-08-14 之前创建的 Python Worker检查代码中是否仍存在顶层on_fetch/on_scheduled函数如有在迁移完成前于wrangler.jsonc中加入disable_python_no_global_handlers以维持运行随后参照本文第四节将处理器逐一切换为Default(WorkerEntrypoint)的类方法删除回退标志并确保compatibility_date不早于 2025-08-14。迁移完成后你将获得与 Workers 平台其他语言一致的结构化入口并天然受益于部署期快照带来的冷启动优化。【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门