如果你曾经因为项目构建一切正常却在部署时被冷冰冰地提示压缩后超过 3 MB而被迫连夜删掉依赖、拆分服务、把数据挪来挪去——那么今天这条消息值得你停下手里的事好好看一眼。根据 Cloudflare 官方更新日志从 2026 年 9 月 4 日起免费版和付费版的 Workers 订阅计划统一支持最大 64 MiB 的未压缩代码包。没错免费套餐和付费套餐现在享受完全相同的代码体积上限这在 Cloudflare Workers 的历史上还是头一遭。过去那套规则说实话相当反直觉。开发者部署项目时Wrangler 等工具会在上传前把代码和依赖打包压缩而 Cloudflare 判断部署是否超限看的是压缩之后的大小免费套餐压缩包超过 3 MB 直接拒绝部署付费套餐超过 10 MB 同样会被拦下。问题在于压缩率本身就不稳定——同样的代码依赖结构稍微复杂一点gzip 压出来的体积可能天差地别。很多人明明项目能正常构建却栽在了这个临门一脚上。现在规则被连根拔起。新方案只看未压缩的软件包大小免费和付费套餐的上限都是 64 MiBGZIP 压缩后的大小降级为纯参考信息不再决定部署成败。这里需要特别提醒一句不能因为数字从 3 MB 变成 64 MiB就简单地说免费套餐容量扩大了 21 倍。新旧两种方案的测量维度完全不同一个是压缩后体积一个是未压缩体积没有直接可比性。但从实际体验来说绝大多数此前因体积被拒的项目现在都能一把通过。部署之前想确认自己的项目会不会触线一条命令就能搞定。使用 Wrangler 工具执行 dry-run 预览构建终端里会输出类似这样的信息wrangler deploy --outdir bundled/ --dry-runTotal Upload: 259.61 KiB / gzip: 47.23 KiB注意看输出里的Total Upload它指的是未压缩的文件大小这才是真正计入 64 MiB 限制的指标后面的 gzip 数值只作展示哪怕它看起来偏大也不用慌。这个细节变化值得每一位使用 Cloudflare Workers 的开发者刻进肌肉记忆。这次调整到底解决了什么痛点说白了就是为大型依赖项和现代框架松绑。这些年 JavaScript 生态的依赖链越来越重一个看似轻量的项目背后可能拖着几百个间接依赖各类框架和生成代码更是体积大户。过去为了塞进 3 MB 的压缩上限开发者们被迫做各种妥协删掉还没用上但迟早要用的库、把一个 Worker 硬拆成好几个、把静态资源搬去 KV、R2 或 D1。这些操作不仅增加工作量还会引入新的架构复杂度。如今 64 MiB 的未压缩空间基本上能让正常规模的项目摆脱体积焦虑。当然兴奋之余也要泼一盆冷水保持清醒64 MiB 仅仅代表代码包体积的上限并不意味着 Worker 的运行时资源跟着水涨船高。免费套餐依旧每天最多 10 万次请求、10 毫秒 CPU 时间、128 MB 内存付费套餐内存同样是 128 MB只是请求次数和 CPU 时间限制宽松得多。换句话说代码能塞进去了跑起来该省的资源还是得省。Cloudflare 官方也专门提醒了一点更大的 Worker 实例可能带来额外的启动开销。所以静态文件、配置文件、大型二进制数据该放 R2 的还是放 R2该走静态资源管线的还是走管线别因为上限变大了就把所有东西一股脑儿打包进实例。体积限制放宽是给你呼吸空间不是给你浪费空间的许可证。回看这次变更信号其实很明确边缘计算平台之间的竞争正在从谁的价格低转向谁的开发者体验好。AWS Lambda 的部署包上限是压缩 50 MB、未压缩含层 250 MBVercel Functions 给到 250 MBGoogle Cloud Run functions 则是压缩 100 MB、未压缩 500 MB。Cloudflare 用一次测量规则的简化把体验门槛拉到了同一起跑线——免费用户和付费用户面对同一套标准部署前的忐忑变成了 dry-run 后的心中有数。对于个人开发者和初创团队来说这无疑是一次真金白银的利好。如果你的项目此前正因为体积问题搁置在 Cloudflare Workers 门外现在是时候重新跑一次 wrangler deploy 了。