服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 自2026年11月17日起，compatibility_date 为2026-11-17或之后的 JavaScript Workers 默认使用新模块注册表；这不是所有 Worker 同时切换的开关。
- Python Workers 继续使用旧注册表。既有 Worker 保持当前行为，直到兼容日期或 flags 改变。
- 要在日期门槛前试用，可在现有兼容配置中加入 new_module_registry；日期达到门槛后要保留旧注册表，则使用 legacy_module_registry，并保留其他 flags。
- 新注册表改进 JavaScript 标准与 Node.js 兼容性；Node.js 兼容模式下 require() 可载入 ES module，但目标模块及全部依赖都不能使用顶层 await。
- import.meta.url、main 和 resolve() 提供模块信息或 bundle 内 URL；resolve() 不检查模块是否存在或从网络加载，构建工具也可能转换 import.meta。
11月17日改变的是默认值，不是所有 Worker 的统一迁移
Cloudflare 在2026年11月2日的公告中说明，从11月17日起，JavaScript Workers 若使用2026-11-17或之后的 compatibility_date，就会默认使用新的模块注册表。注册表负责在 Worker 中定位并加载 JavaScript 模块；这次调整意在提升对 JavaScript 标准和 Node.js 行为的兼容性。
Python Workers 仍使用旧注册表。公告也说明，既有 Worker 会维持当前行为，直到其兼容日期或 flags 被更改。因此，11月17日这个日历日期本身不代表平台会把所有已部署脚本一次性改写成相同配置。
按目标选择试用或保留旧注册表
如果希望在日期门槛前试用新注册表，可以在现有配置中加入 new_module_registry，同时保留原来的 compatibility_date。到门槛日期或之后仍需要旧注册表时，可加入 legacy_module_registry。把这两个 flag 视作有意选择的行为，不要仅因公告发布就批量修改全部项目。
在 Wrangler 配置中变更时，应合并到原有 compatibility_flags 列表，保留项目已经使用的其他 flags；不要用只有一个新 flag 的示例覆盖整份配置。沿用项目现有的配置入口，并核对最终部署的日期和 flags。
先检查 require() 与依赖图中的不兼容点
新注册表改善了与 JavaScript 标准及 Node.js 的兼容性。在启用 Node.js 兼容模式时，require() 可以载入 ES module，但前提是目标 module 以及它的所有依赖都没有顶层 await；只检查入口文件不足以确认这一条件。
新注册表会拒绝无效的 import attributes。切换前应检查实际打包后的依赖图、模块属性和 require() 调用，尤其留意传递依赖是否使用顶层 await。这里的传递依赖，是目标模块继续引用的其他模块。
import.meta 提供信息与 bundle 内解析结果
新注册表支持通过 import.meta.url 读取当前模块的 URL，通过 import.meta.main 判断当前模块是否为入口，并用 import.meta.resolve() 取得另一个模块在 Worker bundle 中对应的 URL。官方示例中，将 src/index.ts 作为未打包入口部署时，isEntrypoint 为 true。
resolve() 返回 URL 不等于确认目标模块存在，也不会替应用从网络载入模块。Cloudflare 还提醒构建工具可能转换 import.meta；若使用打包器，应检查其输出和部署产物，不要直接把未打包示例推定为生产 bundle 的实际行为。
切换前检查什么，怎样判断结果
变更前记录每个环境的 compatibility_date、flags、运行时选项和 bundler 版本，再核对完整模块依赖图、import attributes、require() 路径及 import.meta 的使用。可以在隔离 Worker 中按拟采用的日期和 flags 运行代表性导入场景，并检查构建后的入口与 bundle URL。
这是一份面向迁移准备的检查清单，不代表已在真实 Cloudflare 账户执行了运行时验收。一个配置片段被保存、某个入口成功构建，或 resolve() 返回 URL，都不能单独证明整组生产依赖可用；只有按目标环境验证具体模块图和构建产物，才能判断是否适合调整兼容日期。
资料来源
常见问题
Cloudflare 会在11月17日的哪个时区、具体几点切换？
这则公告公布了日期和 compatibility_date 门槛，但没有注明具体时刻或时区，也没有给出逐账户的启用窗口。不要自行按当地午夜推算；如需安排精确变更窗口，应查看 Cloudflare 后续发布的信息或项目自身的配置状态。
Cloudflare 会自动扫描依赖并生成逐项目迁移报告吗？
公告没有承诺自动依赖扫描或逐项目迁移报告，不能假设平台会预先列出每个传递依赖的问题。应由维护者核对自己的 bundle 和运行时路径；具体工具是否提供额外报告，需以其当前产品说明为准。