配了三年 HTTP 缓存，今天才发现那些 utm 参数全在白占缓存位置——No-Vary-Search 把这件事彻底变了

配了三年 HTTP 缓存，今天才发现那些 utm 参数全在白占缓存位置——No-Vary-Search 把这件事彻底变了

你发了三条链接给用户：

• yoursite.com/landing?utm_source=google
• yoursite.com/landing?utm_source=chatgpt
• yoursite.com/landing?utm_source=linkedin

三个 URL 返回的页面完全一样。但浏览器把它们当三个完全不同的资源存进了磁盘缓存——就因为 URL 长得不一样。

这是 2026 年大多数网站的现状。跟踪参数（utm_source、gclid、fbclid）从来不改变页面内容，却在悄悄把缓存切成无数碎片。

这件事，No-Vary-Search 彻底变了。

它是 HTTP 的一个响应头，服务器用它告诉浏览器：「这些 URL 参数对页面内容没影响，缓存匹配的时候直接忽略。」

No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign" "gclid" "fbclid")

加上这一行之后，上面三个 URL 共享同一份缓存条目。磁盘命中率直接上去，用户点进来的等待时间直接下来。

真实案例

一位工程师在三个站点上实测，步骤很简单：给搜索页和落地页的 HTTP 响应加上这个头。效果：

• 同一页面不再因为跟踪参数不同而产生多份缓存
• 预取/预渲染的缓存复用率同步上升（因为浏览器知道哪些 URL 本质上是同一个资源）
• 源站请求减少，CDN 验证流量下降

他自己说的：「让缓存重新流行起来。」（Make cache popular again.）

不只是跟踪参数

key-order 参数还有更细的用法——有些应用的查询参数顺序不固定，但内容相同：

No-Vary-Search: key-order

这行表示「参数顺序不同也算同一个资源」，不用再担心 ?a=1&b=2 和 ?b=2&a=1 被当成两个不同的 URL。

浏览器支持情况

• Chrome/Edge：127+ 完整支持
• Firefox：154+ 完整支持（2026 年 8 月随正式版发布）
• Safari：暂不支持

不支持的浏览器会直接忽略这个头，不影响正常逻辑，可以直接上。

下一步

第一步：翻出你的落地页和搜索页响应逻辑，确认哪些参数真的不影响内容。

第二步：在 Nginx / Express / CDN 边缘加这个响应头，从 utm_* 和 gclid 开始。

第三步：用 Chrome DevTools 的 Network 面板看缓存状态变化，注意同一个资源 URL 后面有没有多个参数变体被合并成一条。

这件事很小，小到很多人觉得不用管。但你的用户每一次从广告落地页点进来，都在为那些「长得不一样但内容一样」的缓存碎片付代价。