服务器还在给你发 gzip，浏览器早就不想解了——zstd 进 Baseline 半年，你可能一个字节的带宽都没省下来

如果你的服务端还在无脑发 Content-Encoding: gzip，那么从 2026 年 2 月起，你已经在为一个过时的默认值持续付费了——zstd 正式进入 Baseline，而你的响应体还停留在 1990 年代的压缩算法上。

先给结论：zstd（Zstandard）不是「又一个压缩算法」，它是唯一一个让你同时省带宽、省服务端 CPU、还不用改一行前端代码的选项。 你要做的只有三件事：确认服务端能签发 zstd、把静态资源在构建期压成 .zst、把 Vary: Accept-Encoding 配对。

为什么 zstd 值得你现在就切

HTTP 压缩这件事几十年没变过：浏览器在 Accept-Encoding 里列出自己支持的算法，服务端挑一个，用 Content-Encoding 告诉对方选了谁，浏览器自己解压。全程对用户透明，浏览器不支持就自动回退。

问题出在「挑哪个」上。gzip 是 90 年代的默认值，Brotli 是 2015 年 Google 的升级，压缩率比 gzip 高 15%–25%，但 CPU 代价明显更高，尤其在高压缩等级下。zstd（RFC 8878，Meta 出品）卡在两者之间：据 Cloudflare 的基准，相同压缩率下 zstd 比 Brotli 快约 42%，比 gzip 也快约 43%，同时产出更小。

落到具体数字上更直观。一份 226 KB 的 JSON 响应：

• gzip level 6：68.2 KB，耗时 4.8 ms
• Brotli level 4：61.5 KB，耗时 6.1 ms
• Brotli level 11：54.3 KB，耗时 312 ms
• zstd level 3：59.8 KB，耗时 2.7 ms
• zstd level 9：56.1 KB，耗时 8.2 ms

关键在最后一列：zstd level 3 比 gzip-6 和 Brotli-4 都小，而且三者里最快。而 level 9 已经逼近 Brotli-11 的压缩率，CPU 成本却只是零头。对动态内容——HTML 页面、JSON API 响应、SSR 出来的标记——这个差距是实打实的，因为压缩要在每次请求上实时跑。

兼容性：已经足够安全

很多人对 zstd 的印象还停留在「实验性特性」。截至 2026 年，情况已经反过来：

• Chrome / Edge / Opera：Chromium 123+（2024 年 3 月）
• Firefox：126+（2024 年 5 月），Firefox for Android 126+
• Safari：26+（macOS Tahoe，部分支持），iOS/iPadOS 26.3 起完整支持

全球覆盖率已超过 95%。而且它是加法型特性：浏览器不支持就压根不会在 Accept-Encoding 里写 zstd，服务端自然回退到 Brotli 或 gzip。不存在「加了 zstd 老浏览器就炸」这回事。

三个必须知道的坑

一、只有 HTTPS 才会协商 zstd。 Chrome、Edge、Firefox、Safari 都只在 HTTPS 下才在 Accept-Encoding 里广告 zstd。明文 HTTP 请求一律回退 gzip，哪怕两端都支持。如果你还在部分路径上跑 HTTP，那部分流量永远吃不到红利。

二、Vary: Accept-Encoding 不写，CDN 会下毒。 少了这个头，CDN 可能给 gzip 客户端返回一个 Brotli 的 body，客户端解不开。这是缓存投毒级别的 bug，不是小疏忽。

三、DecompressionStream 至今不支持 zstd。 浏览器端要解 zstd 还得靠 zstd-wasm 之类的 polyfill。所以策略要分清楚：传输层用 zstd，应用层别指望浏览器原生解压。

落地路径（按性价比排序）

第一步：动态响应先切，收益最快。 静态资源变化少，收益有限；而每次请求都要实时压缩的动态内容才是大头。Nginx 用 zstd 模块（tokers/zstd-nginx-module），Caddy 原生支持，Node.js 用 @mongodb-js/zstd 或内置支持，Cloudflare 控制台直接开。配置完用一行命令验证：

curl -I -H "Accept-Encoding: zstd" https://your-site.com/api/data
# 看返回头里有没有 content-encoding: zstd

第二步：静态资源构建期预压缩。 打包出来的 JS/CSS 不会变，构建时用最高等级压成 .br 和 .zst，服务端直接读现成文件，运行时零 CPU。这一步最适合接进 CI。

第三步：警惕静默降级。 有些 CDN 会在回源时剥掉 Accept-Encoding: zstd，然后在边缘用低等级重新压一遍——你以为吃到了 zstd，实际拿到的是被降级的 Brotli。验证方法：在 cache miss 时抓 Vary: Accept-Encoding 日志，确认边缘是真的给 Chrome 发了 zstd、给 Safari 发了 Brotli，而不是两个都发 Brotli。

一句话收尾

zstd 进 Baseline 半年，真正的成本不是「要不要支持」，而是你的服务端默认值还停在 gzip。这不是一个需要全量重构的改动，它是部署配置里几行的事——但省下来的带宽和 CPU，会按每个请求、每个用户复利式地堆起来。先去跑那行 curl 看看你现在的响应头吧。