如果你照着 2026 年之前写的 Cloudflare 教程操作过,装过名字里带 “resizing” 的插件,或者接手过一个重写图片 URL 的 Worker,你多半已经撞上了一件让人困惑的事:Cloudflare 控制台里再也没有叫 Image Resizing 的功能,文档里也不提它了。你的配置并没有坏掉,只是你要找的那个名字悄悄消失了。

这个功能现在叫 Image Transformations。它做的是同一件事,走同一套 URL 结构,用同一批参数。变的是名字、它在控制台里的位置,以及计费方式。最后一点值得仔细读,因为计费模型和大多数旧教程描述的确实不一样。

一句话概括: 你现有的 URL 和 Worker 照常工作。Cloudflare 把 Image Resizing 改名为 Image Transformations,并并入了 Cloudflare Images 产品。免费套餐现在每月包含五千次唯一转换,这是新增的,超出部分按千次计费,而不再需要 Pro 订阅。


到底改了什么

改名是看得见的部分,但同时动了三件事,把它们混在一起正是大部分误解的来源。

名字。 Image Resizing 变成了 Image Transformations。Cloudflare 自家文档通篇使用新术语,完全没有提到旧名,所以用旧名搜索越来越多地导向第三方页面,而不是官方文档。

产品边界。 转换功能以前像是一个独立开关。现在它位于 Cloudflare Images 内部,那是涵盖存储与分发的更大产品。这带来一个应当立刻澄清的误解:你并不需要把图片存在 Cloudflare Images 里才能转换它们。你可以转换放在自己源站、R2 里,或者其他任何可公开访问位置的图片。存储和转换是两件独立的事,只是碰巧共用一个产品页面。

计费。 这才是实质性的变化。旧教程告诉你图片缩放需要 Pro 或更高套餐,现在已经不是这样了。免费套餐就能用,这也意味着很多当初因为价格而放弃这个功能的小站点,现在值得重新评估一次。


现在的费用

免费套餐每月提供五千次唯一转换,不收费。超出之后,在付费的 Images 套餐上,价格是每月每千次唯一转换五十美分。

这里起决定作用的词是"唯一"。转换按源图与参数的每个不同组合计算,每个自然月计一次。把一张照片缩到一百像素宽,再缩到两百像素,是两次转换。但把同一个一百像素版本在当月分发给五万名访客,仍然只算一次,因为重复请求不产生费用。

这个区别比标价更重要。你的账单随站点产出的不同图片变体数量增长,而不随流量增长。一个图片少而稳定的高流量站点,能舒服地待在免费额度内。一个目录庞大、断点繁多的站点,无论访客多少都会把额度用完。

格式转换的计数方式里还有一个有用的细节。如果你使用自动格式参数,Cloudflare 给一部分浏览器发 AVIF、给另一部分发 WebP,这算作一次转换而不是两次。从计费角度看自动格式选择实际上是免费的,这就是优先用它而不是显式指定格式的充分理由。


你需要更新什么

对大多数配置来说,功能层面什么都不用改。URL 格式没变,参数没变,构建转换 URL 的 Worker 也和以前一模一样。这是一次改名,不是一次迁移。

值得更新的是所有还在指向旧名字的东西,因为那些引用现在会把人送去找一份已经不存在的文档。

内部文档和运维手册是最明显的一类。如果你的部署笔记写着"在控制台启用 Image Resizing",下一个照做的人是找不到那个设置的。

插件和工具的名字是尴尬的一类,包括我自己的。我维护的 WordPress 插件仍然叫 Cloudflare Image Resizing,因为给已发布的插件改名会破坏现有安装和搜索连续性。它和 Image Transformations 的配合与从前完全一样。如果你在 WordPress 插件目录里搜索,预计还会碰到旧术语一段时间。

监控和成本告警值得再看一眼。如果你围绕旧的套餐分级模型设置了账单告警,它监视的是一件已经不适用的事。现在该盯的是唯一转换次数相对每月五千的额度。


大家容易踩的坑

有两个反复出现的错误,两者都是花钱而不是弄坏东西。

生成超出需要的变体。 由于计费跟随不同变体,一个有八个断点的响应式配置会把你的转换次数乘以八。大多数站点不需要八个。三到四个选得当的宽度就能覆盖现实中的设备范围,每去掉一个就是按比例的节省。我们关于响应式图片的指南讲了如何挑选真正值得保留的断点。

破坏缓存的查询字符串。 如果你的构建流程给图片 URL 附加一个会变化的版本参数,那么每次部署都会产生一批全新的唯一转换。这是站点在不知不觉中堆高转换账单最常见的方式:图片没变,但 URL 变了,于是 Cloudflare 把每一个都当成新的。


确认它真的在生效

正因为改了名,确认比想当然更重要,因为配置错误是静默失败的。你的图片照样加载,只是未经转换以原始尺寸送出,唯一的症状就是页面慢。

最快的检查是图片请求的响应头。经过转换的响应会带一个 cf-resized 头说明做了什么,content-type 则反映实际送出的格式。如果你请求了自动格式选择,而现代浏览器仍然收到原始 JPEG,那转换就没有生效。

第二个检查是传输体积。打开网络面板刷新,把某张图片的传输大小和源站上的原始文件对比。一张以磁盘上同样字节数抵达的照片,就是根本没被处理过。这能抓住那种 URL 模式有细微错误、请求直接穿过去的常见情况。

值得知道的是:转换只对通过启用了该功能的区域分发的图片生效。如果你的图片在一个未经 Cloudflare 代理的子域上,或者你从账户之外的第三方主机拉取,请求会绕过整套机制。这在迁移之后最容易坑人,图片 URL 被重新指向后,没人再核对到底是哪个主机名在提供服务。


到底该不该用

转换适合图片尺寸不一或来自用户上传的站点,以及预先生成并存储每个变体并不现实的场合。同一张照片既作缩略图、又作网格瓦片、又作完整视图的商品目录,就是最自然的例子。编辑上传相机直出文件、而你需要它不经人工处理就能用的站点也一样。

如果你的图片集合很小、固定、极少变动,它就没那么合适。那种情况下在构建时生成一次尺寸并作为静态文件分发,成本为零,没有哪个转换服务能赢过免费。

想更完整地了解 URL 方式与 Worker 方式的差别,请看我们的 Cloudflare Image Transformations 指南。如果你还在权衡图片本身该放在哪里,用 Cloudflare R2 托管图片讲了存储这一侧以及它为零的出站费用。


把它配置妥当

图片分发的大部分价值来自那些做一次就不再动的决定:你实际分发哪些宽度、格式选择是否自动、你的 URL 是否稳定到能吃上重复请求的折扣。这些在一开始很快就能做对,事后再拆解则相当费劲。

Mecanik 在网站开发工作中构建并审计图片分发,而在 WordPress 上把这件事自动化的 WordPress 插件是免费的。如果你的站点很慢并且怀疑是图片的问题,一次 WordPress 性能审计会在你花钱之前告诉你这个直觉对不对。



常见问题

Cloudflare Image Resizing 停用了吗? 没有。它被改名为 Image Transformations,并并入 Cloudflare Images 产品。URL 格式、参数和 Worker 集成都没有变化,因此现有配置无需修改即可继续工作。

图片缩放还需要 Pro 套餐吗? 不需要。那个要求属于旧模型。免费套餐现在每月包含五千次唯一转换,超出部分在付费 Images 套餐上按每千次五十美分计费。

什么算一次唯一转换? 源图与参数的一个不同组合,每个自然月计一次。把同一张已转换的图片发给很多访客算一次。把同一张图片按两种宽度请求则算两次。

必须把图片存在 Cloudflare Images 才能转换吗? 不必。你可以转换放在自己源站、R2 或其他任何可公开访问位置的图片。存储和转换是分开的,尽管它们现在共用一个产品页面。

为什么这个 WordPress 插件还叫 Image Resizing? 给已发布的插件改名会破坏现有安装和搜索连续性,所以名字保持不变。它与 Image Transformations 的配合和以前一样,因为改变的只是 Cloudflare 的术语。