浏览器选错了 Favicon？开发者的真正修复方案

你刚更新完 favicon，重新部署了新文件，也刷新了页面——浏览器却还在显示错的图标。可能是半年前的老 logo，可能是别的站点的图标，又或者是一个不该出现的模糊占位图。

这是开发者最容易踩到的 favicon 坑之一。文件明明躺在服务器上，HTML 标签看着也没毛病，浏览器却偏偏选错了 favicon，把你刚部署的东西晾在一边。

先上快速修复方案，再讲为什么会这样。

两分钟快速修复

绝大多数"favicon 选错"的症状都指向同一个根源：浏览器优先级。当存在多个图标源时，浏览器会按严格的查找顺序来解析，任何冲突都会劫持最终结果。

先按这个清单过一遍：

删除站点根目录下的 /favicon.ico。在很多浏览器里，它会覆盖 HTML 里的声明。
在 <head> 里显式声明 rel="icon" 标签，带上正确的 sizes 和 type 属性。
给链接加上缓存破坏查询字符串（比如 ?v=2），强制浏览器去拉新文件。
用 Ctrl+Shift+R 强制刷新，或者照我们的 favicon 缓存清理指南处理顽固情况。

如果问题解决了，到此为止。如果没有，说明浏览器选错 favicon 是因为优先级冲突——接下来进入深度排查。

为什么浏览器会挑错图标

浏览器不会无脑相信你的 HTML。它们按 HTML 规范定义的查找顺序来解析，任何不匹配都可能劫持最终结果。

1. /favicon.ico 陷阱

如果站点根目录下还放着一个旧的 favicon.ico，同时 HTML 里又声明了现代的 <link rel="icon"> 标签，浏览器通常会优先选 ico 文件。很多浏览器在没有任何图标声明时会自动请求 /favicon.ico，而一旦这个文件存在，就会把它当成权威。

修复办法：删掉根目录的 favicon.ico，或者通过 link 标签显式声明它，并配上精确的 sizes 属性，让浏览器知道它到底是什么尺寸。

2. 缺失或错误的 sizes 属性

sizes 属性用来告诉浏览器每个图标文件的分辨率。如果不写，浏览器可能把 16x16 的 PNG 强行放大到 32x32 的上下文里显示——结果就是大家都很嫌弃的那种像素糊脸效果。

一定要显式声明：

<link rel='icon' type='image/png' sizes='32x32' href='/icons/favicon-32x32.png'>
<link rel='icon' type='image/png' sizes='16x16' href='/icons/favicon-16x16.png'>

HTML 规范把 rel="icon" 定义为声明站点图标的标准方式。具体解析规则可以看 WHATWG HTML Living Standard。

3. type 属性冲突

如果你声明的是 type="image/svg+xml"，但实际返回的是 PNG（或者反过来），浏览器可能直接跳过这个文件，回退到任何其他可用资源——包括缓存里的旧版本。

确认你的 MIME 类型和实际文件一致。一个常见 bug：CDN 在文件扩展名和 HTML 属性都标明是 SVG 的情况下，仍然返回 image/png。

4. Web App Manifest 覆盖

当站点有 site.webmanifest 并且包含自己的 icons 数组时，浏览器可能会优先选用 manifest 里的图标，而不是 HTML 中的 link 标签——尤其是在移动端和"添加到主屏幕"的流程里。

检查 /site.webmanifest，确保 icons 数组指向的文件和 HTML 声明的一致。尺寸或格式不匹配会让浏览器按照特定平台的逻辑选错 favicon。

5. CDN 与边缘缓存滞后

Cloudflare、Fastly 以及类似的 CDN 都会激进地缓存静态资源。哪怕你已经完成部署，边缘节点仍然可能继续返回旧版 favicon，持续数小时甚至数天。

每次部署后，记得清掉 CDN 上 /favicon.ico、/icons/* 和 /site.webmanifest 路径的缓存——否则浏览器选错 favicon 纯粹是因为边缘节点陈旧。

6. Service Worker 陷阱

Service Worker 可以独立于浏览器 HTTP 缓存来缓存 favicon 响应。如果你的 PWA 在首次安装时就缓存了图标，用户就会一直看到旧版本，直到 Service Worker 更新。

升级 Service Worker 版本，并在 href 里加上缓存破坏查询字符串。给文件名加版本号更稳妥。

预防：打造一套经得起折腾的图标方案

解决眼前的故障之后，再加固一遍配置，防止"favicon 错乱"再次发生：

单一来源：按规范的 favicon 生成流程，从一个源文件生成所有图标。
命名一致：使用专门的 /icons/ 目录，不要直接放在站点根目录。
部署时破坏缓存：在构建流程里给文件名加哈希（例如 favicon-abc123.png），让旧缓存彻底失效。
定期审查：每次大版本发布前，在各种浏览器里做一轮快速审计。
用无痕模式测试：无痕窗口会绕过大部分缓存层，给你看一个真实的预览。

总结

浏览器选错 favicon 文件几乎从来不是随机的。它要么在执行你没注意到的优先级顺序，要么从一个忘记失效的缓存里读取，要么看到的 type 属性和实际返回的文件不匹配。

清理掉根目录的 favicon.ico，显式声明带正确 sizes 和 type 的 link 标签，保持 manifest 同步，并在每次部署时清缓存。按这个顺序走，绝大部分"favicon 错乱"案例都能解决——剩下的边缘案例基本都指向 CDN 或 Service Worker 陷阱，用 DevTools 花几分钟就能定位。