现代浏览器已统一支持rel="icon"，rel="shortcut icon"是IE旧版非标写法且W3C未定义，继续使用无益反可能触发构建警告；.ico文件必须配sizes="any"且Content-Type为image/x-icon，PNG需写真实尺寸如32x32，路径须用绝对路径以避免404。
rel="shortcut icon" 已是过时写法，现代浏览器完全支持 rel="icon"，继续用 shortcut icon 不但没额外收益，反而可能在某些构建工具或 Linter 中触发警告。
为什么 rel="shortcut icon" 不再需要
Chrome、Firefox、Edge 从 2010 年代中期起就统一将 rel="icon" 视为标准标识；shortcut 前缀仅在 IE6–IE9 中有历史作用，而这些浏览器早已退出主流。W3C 规范中从未正式定义 shortcut icon，它只是微软当年的非标扩展。
- 写
<link rel="shortcut icon" ...>和<link rel="icon" ...>效果完全一致——浏览器只认rel="icon"部分 - 若同时存在两条，浏览器按声明顺序选第一个匹配项，不会“叠加”或“优先级提升”
- Vite/Next.js 等现代框架的 HTML 插件（如
vite-plugin-html）默认忽略shortcut，部分 CI 构建会报invalid rel value
rel="icon" 必须带 sizes 才生效？
不是必须，但对 .ico 文件，sizes="any" 是硬性要求。Chrome 94+ 开始强制校验：若 rel="icon" 指向 .ico 却没写 sizes="any"，该条目直接被跳过，控制台无提示。
-
<link rel="icon" type="image/x-icon" href="/favicon.ico">→ ❌ Chrome 不加载 -
<link rel="icon" type="image/x-icon" sizes="any" href="/favicon.ico">→ ✅ 正常加载 -
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32.png">→ ✅ PNG 必须写实际尺寸，不能写any -
sizes值必须与文件真实分辨率严格一致，写成32x32而非32或32px
服务器返回的 Content-Type 错了，rel 写得再对也没用
浏览器收到 favicon 响应后，会比对 type 属性和响应头中的 Content-Type。二者不一致，图标直接丢弃，且 DevTools Network 面板里可能只显示 200 却无渲染——连错误提示都没有。
-
.ico文件必须返回Content-Type: image/x-icon，Nginx 需在types块中显式声明：image/x-icon ico; -
.png必须是image/png，不是text/plain或空值 - 本地开发时用
file://协议，所有Content-Type都是text/plain，favicon 必然失效——必须走 HTTP(S) 服务 - 用
curl -I https://yoursite.com/favicon.ico直接检查响应头最可靠
路径写错比代码写错更常见
绝大多数 favicon 不显示问题，根源不在 HTML 标签，而在路径解析失败。浏览器对 favicon 的路径处理比普通资源更“固执”：
- 相对路径（如
href="images/favicon.ico"）在子页面（如/blog/post.html）中会解析成/blog/images/favicon.ico，404 - 务必用绝对路径：
href="/favicon.ico"，开头的/表示根目录 - 即使你写了
<link href="/assets/icons/favicon.ico">，浏览器仍会额外发一次GET /favicon.ico请求——如果该路径 404，部分浏览器（尤其是旧版 Chrome）会降级忽略整个图标系统 - 检查方式：DevTools → Network → 过滤
favicon→ 看请求 URL 是否是你期望的地址
真正卡住人的往往不是语法，而是服务器 MIME 配置、路径解析规则、以及浏览器对 sizes 和 Content-Type 的静默丢弃逻辑——这些地方出错，连控制台都不会报红字。
