Cloudflare Workers 统一 64 MiB 大小限制：不必再为包体积升级付费

Cloudflare 刚刚取消了仅因包体积而购买 Workers Paid 的理由。自 2026 年 9 月 4 日起，原先 Workers Free 3 MB、Workers Paid 10 MB 的压缩后检查统一改为两种方案均采用 64 MiB 未压缩上限；现在衡量 Cloudflare Workers 部署预算应看 Wrangler 的 Total Upload，而不是 gzip。

Cloudflare Workers 大小限制究竟改了什么

Worker 包是部署时提交给 Cloudflare 的代码及配套模块。Cloudflare 的命令行工具 Wrangler 默认使用 esbuild 构建上传内容，同时打包代码所导入的 npm 包，并报告最终大小。

在 9 月 4 日之前，Cloudflare 会压缩这个包；压缩结果一旦超过 Workers Free 的 3 MB 或 Workers Paid 的 10 MB，部署就会被拒绝。如今这项压缩检查已取消。

平台现在只检查一项：未压缩的 Worker 包不得超过 64 MiB。Free 与 Paid 采用同一上限。

最后一列就是这次调整的关键。Total Upload 表示未压缩大小。Wrangler 仍会输出 gzip 供参考，但 Cloudflare 已不再用它决定部署是否放行。

不要把这次变化简单换算成倍数。旧上限以 MB 衡量压缩后字节数，新上限则以 MiB 衡量未压缩字节数。究竟能多容纳多少代码，取决于项目中的 JavaScript、依赖项和二进制模块能被压缩到什么程度。

是否升级 $5 方案，判断依据变了

这项变化对成本决策的影响很明确，也很实用。Workers Paid 每个账号每月至少收费 $5 USD。如果团队过去只是因为包体积超过 Workers Free 原有的 3 MB 上限而准备升级，那么只要 Total Upload 不超过 64 MiB，这个升级理由就不存在了。

但这不代表两个方案已经完全相同。Workers Free 仍包含每天 100,000 次请求、每次调用 10 毫秒 CPU 时间，以及每次调用 50 个子请求。Workers Paid 则包含每月 1000 万次请求和 3000 万 CPU 毫秒，允许每次调用发起 10,000 个子请求；每个请求最多可使用 5 分钟 CPU 时间，默认值为 30 秒。

因此，预算判断反而更清晰了：应为流量、CPU、子请求和 Paid 专属能力付费，而不是仅仅因为一个可压缩的包超过了已经废止的 Free 门槛就付费。

已经因为真实生产负载使用 Paid 的团队，不会直接看到费用下降。原本就远低于旧上限的项目，工作流也不会变化。真正受益的是那些曾因部署包大小而删减依赖、拆分项目或升级方案的团队。

至于账号和运行时的其他成本，这篇更完整的 Cloudflare 评测说明了 Workers 与 Cloudflare 其他方案及用量费用之间的关系。文中的旧包大小上限，正是此次 9 月调整所取代的部分。

四类构建会变得更轻松

独立 SaaS 创业者不必再把方案选择和框架选择绑在一起

假设正在 Workers Free 上发布一款全栈应用。框架适配器、服务端渲染代码和生产依赖组合起来后，即便应用流量仍在 Free 配额内，压缩包也可能超过旧有的 Free 上限。

现在只需用 64 MiB 的 Total Upload 来判断这次构建。只要没有超限，包体积本身就不会迫使项目承担 $5 的 Paid 最低费用。这里的价值并不是任何规模的生产服务都能免费运行，而是可以先验证需求，无需提前为尚未用到的运行时用量付费。

代理机构可以删掉已经失效的 CI 门禁

代理机构的构建负责人可能早已把旧 gzip 阈值复制到每个客户仓库。继续保留这项检查，会让构建因为一条 Cloudflare 已不再执行的规则而失败。

应改为检查未压缩的 Total Upload，并在 64 MiB 以下设定团队自己的上限，预留余量。这样，客户项目触发的是平台当前的约束，而不是一条历史规则。

Rust 或 WebAssembly 团队获得的是更大空间，而不是新运行时

WebAssembly 通常简称 Wasm，它让 Worker 能够运行由 Rust、Go 或 C 等语言编译出的二进制代码。Cloudflare 指出，Wasm Worker 通常比同等功能的 JavaScript Worker 更大，因为二进制文件往往还带有额外的运行时依赖。

部署容量提高后，Wasm 模块及其周边代码有了更多空间。Wrangler 可直接上传 .wasm 和 .wasm?module。体积优化依然重要，Cloudflare 建议使用 wasm-opt 来缩减二进制文件。

平台团队可以淘汰只为绕过限制而设计的架构

使用 Workers Paid 的平台工程师，可能只是为了把压缩包控制在 10 MB 以下，便拆分了本应完整的服务、移除了有用的依赖，或自行搭建外部模块方案。现在值得重新审视这些决定。

有些拆分应当保留，因为它们划清了合理的归属边界或故障边界。但如果某项拆分只是为已经废止的上传检查而存在，它就成了失去平台约束依据的额外复杂度。

下次部署前，先检查真实的 Worker 包

无需根据 node_modules、源码目录或其他框架构建流程生成的归档大小来猜测。应在 Worker 项目中执行 Wrangler 的模拟部署，让它构建 Cloudflare 实际会收到的产物。

1. 1

   只构建，不部署

   运行 Cloudflare 文档中的模拟部署命令：

   wrangler deploy --outdir bundled/ --dry-run

   Wrangler 会构建 Worker 并把输出写入本地，但不会执行部署。

2. 2

   读取 Total Upload

   在命令输出中找到 Total Upload。它就是 Cloudflare 目前用于对照 64 MiB 上限的未压缩包大小。gzip 仍可作为诊断参考，但不要再把它当作平台判定部署成败的指标。

3. 3

   调整 CI 体积预算

   把所有针对 Workers Free 3 MB 或 Workers Paid 10 MB 压缩大小的规则替换为 Total Upload 规则。团队自己的上限应低于平台最大值，以免一次依赖更新就耗尽全部余量。

4. 4

   在真实部署中观察启动时间

   下次正常部署或上传版本时，记录 Wrangler 输出的 startup_time_ms。即使包体积符合上传限制，仍可能无法通过 Cloudflare 另一项独立的启动检查。

最常见的错误，是因为 gzip 数值看起来更小、过去又确实决定部署结果，便继续盯着它。现在真正的预算线是 Total Upload。

64 MiB 并没有同步放宽真正的运行限制

包越大，解析和初始化可能越慢。如果代码在全局作用域，也就是请求处理程序之外执行高开销任务，验证时仍可能出现 Script startup exceeded CPU time limit，并返回错误代码 10021。低于 64 MiB 只代表通过体积门禁，并不保证可以正常启动。

重型框架和 Wasm 尤其需要注意这一点。过去，旧上限往往会先阻止上传；现在更多代码能进入下一道约束，内存占用和初始化行为也会随之暴露出来。

如果 Worker 仍然过大，当前文档给出了三条实用出路：

• 删除部署路径并未使用的包和依赖。
• 将配置、静态资源和二进制数据放入 Workers Static Assets、KV、R2 或 D1，而不是塞进 Worker 包。
• 通过 Service Bindings 把功能拆分到多个 Workers 中。

Service Binding 调用不会产生第二笔请求费用。Cloudflare 只对最初的 Worker 调用，以及所有相关 Workers 合计使用的 CPU 时间计费。因此，拆分确实可以解决体积问题，但引入额外服务边界仍应是有意识的选择。

下周一该怎么做

如果某个 Worker 最近未能通过旧版大小检查，如果团队为了不超限而删减过框架依赖，或者包体积曾是升级 Paid 的唯一理由，就应在本周行动：执行模拟部署、记录 Total Upload，然后重新评估原来的决定。

如果 Worker 原本就远低于旧上限，而且部署流水线没有写死的 gzip 门禁，可以暂时不动。应用的运行时没有发生任何变化。

如果请求量、CPU 时间、子请求或其他 Paid 能力足以支撑付费理由，就继续使用 Paid。Free 方案扩大上传上限，并不意味着应把生产负载迁移到运行配额并不匹配的方案上。

下周一要做的事很简单：把构建检查从 gzip 改为 Total Upload，再根据实际用量而不是包体积选择方案。

通过邮件通讯获取下一项值得采取行动的平台变化。