rel="icon"标签必须唯一且置于head最顶部，浏览器仅加载第一个并短路后续所有同rel图标；apple-touch-icon与manifest需严格后置，preload和crossorigin对图标无效。
rel="icon" 一定是第一个被加载的图标资源
浏览器在解析 <head> 时，只要遇到第一个 <link rel="icon">，就会立即发起请求，且不阻塞 HTML 解析、不参与渲染树构建。它优先级高于所有其他 rel 值的图标标签——不管后面有没有 rel="apple-touch-icon"、rel="manifest" 或多个 rel="icon"，只有第一个成功响应的 rel="icon" 会被用于地址栏和标签页显示。
多个 rel="icon" 标签不会并行加载，只用第一个
常见错误是写一堆不同格式的图标来“兼容”：
<link rel="icon" href="/favicon.ico"> <link rel="icon" href="/favicon.svg" type="image/svg+xml"> <link rel="icon" href="/favicon.png" sizes="32x32">
实际效果是：浏览器按顺序尝试，一旦 /favicon.ico 返回 200，后面两个就完全被忽略；即使 .ico 404 了，才会继续试 .svg，以此类推。这不是容错机制，而是明确的“短路逻辑”。所以：
- 不要堆砌多个
rel="icon"，只留一个最稳的（推荐16x16或32x32PNG） - 如果要用 SVG，确保服务器返回正确的
Content-Type: image/svg+xml，否则可能静默失败 -
sizes属性对rel="icon"仅作提示，浏览器不强制校验尺寸，但写错（如sizes="16x16 32x32"）可能让某些旧版 Edge 忽略整条标签
rel="apple-touch-icon" 不会抢跑，但位置靠后会影响首帧图标
Safari 在解析到 <link rel="apple-touch-icon"> 时，会把它当“潜在主屏图标”提前发起请求，但它不参与地址栏图标选择。关键点在于：
立即学习“前端免费学习笔记（深入）”；
- 如果它写在
rel="icon"之后，Safari 可能因并发请求数限制或资源竞争，延迟触发rel="icon"的加载，导致标签页图标“闪一下空白再出现” - 必须显式写
sizes="180x180"，否则 Safari 会尝试缩放其他尺寸图标，产生模糊或额外请求 - 它和
rel="icon"是两条独立路径，混写不互补，只增加竞态风险
preload 对图标无效，还可能引发重复请求
你写 <link rel="preload" href="/favicon.ico" as="image">，浏览器大概率会下载它，但不会把它当 favicon 使用——因为 rel="icon" 的加载逻辑是硬编码在解析器里的，和 preload 无关。更糟的是：
- 如果同时存在
<link rel="icon" href="/favicon.ico">和上面这行 preload，Chrome 会发两次请求 -
as="icon"是非法值，规范里没有，必须用as="image" - 加
crossorigin没意义，图标不走 CORS 流程，反而可能触发预检请求失败
真正该做的，只是把 <link rel="icon" href="/favicon.png"> 放在 <head> 最顶部，其他图标标签全删掉或严格按 icon → apple-touch-icon → manifest 顺序排列。复杂点在于：浏览器不报错，也不警告你图标没生效——它只是默默换了一个默认图标，而你得靠肉眼对比才知道。
