WordPress 7.1 “Mary Lou” 在 2026 年 8 月 19 日发布，代号来自爵士钢琴家 Mary Lou Williams——六岁开始公开演奏的神童，1940 年代把自己在哈莱姆的公寓变成 Thelonious Monk、Dizzy Gillespie、Bud Powell 夜间切磋 bebop 的工作坊。官方发布文用她的“reinvention and collaboration”贯穿这次更新：响应式样式控制、新的媒体编辑器、带 @提及和富文本的 Notes、Playlist 和 Tabs 两个新块。
但这些用户看得见的功能背后，藏着一个更值得注意的架构转折。标题为 Client-Side Media Processing in WordPress 7.1 的 Make Core dev note 宣布：图像压缩、缩放、裁剪、格式转换（JPEG/PNG/WebP/AVIF/GIF）、EXIF 旋转和渐进/隔行编码，全部通过 WebAssembly 在一个 Web Worker 里完成。上传时浏览器先在本地把图片处理好，再上传更小的文件——用官方发布文的话说，是 “without hitting PHP memory limits or upload timeouts”。服务器负载和 PHP 内存压力被绕开了，文件也更小。
具体行为变化相当实在。HEIC/HEIF（iPhone 默认格式）在浏览器里解码、转成 web-ready JPEG 上传，原始 HEIC 作为 companion file（source_image）保留，附件删除时一起清理；AVIF 可以端到端上传，即使主机 PHP 图像编辑器根本不支持 AVIF；10 或 12 位的高比特深度源图在生成的子尺寸中保留位深；带 HDR gain map 的图片原样上传，gain map 在所有子尺寸中幸存。连不透明的 animated GIF 都会被转成 companion video。已有的 image_editor_output_format filter 在客户端同样被尊重——不是另起炉灶，而是把既有规则搬到了浏览器里执行。
这个设计把“主机必须装对 GD/Imagick 和对应扩展”的部署约束，平移到了用户浏览器。但依赖并没有消失，只是换了宿主：dev note 明确说 HEIC 解码依赖平台 codec，Gutenberg issue #81043 记录了一个反例——Windows 上缺 HEVC codec 时，HEIC 上传会无限挂起，而不是回退到服务端。这是一个很有说明性的失败模式：以后“能不能上传这张图”不再由你的主机决定，而是由你的操作系统和浏览器决定。服务器端图像编辑器从主角退化为兜底，兜底只有在浏览器帮不上忙时才出手。
这个转折的长期后果还不清楚。同一周发布的 WCUS 2026 recap 里，社区讨论的已经是大模型时代的判断力、信任与 Abilities API（7.1 为它加上了可过滤的执行生命周期和自定义校验，官方明说目的是 “including AI-powered tooling”）。而 7.1 把图像处理搬进浏览器这件事，恰好是 WordPress 从 PHP 应用朝“端到端平台”移动的又一个切片：主机能少做的事越来越多，代价是 WordPress 的媒体管线从此与浏览器能力（以及平台 codec）深度耦合。下一步值得追问的是：WordPress 会继续把多少服务端能力搬进 wasm，以及服务端兜底会不会在某个版本里被彻底拆掉。
✦回复与讨论