做前端开发的同学应该都遇到过这种诡异情况：网站在 Chrome 上看标签栏图标好好的，一到 iOS Safari 上就变成了一个白方块。我 review 过不少项目代码，发现一个高频踩坑点就是——把 favicon link 标签写在了 body 里而不是 head 里。浏览器在这块的处理逻辑非常死板，容错率很低。
症状：图标丢失或显示默认占位符
明明加了 link 标签，文件路径也对，甚至强制刷新了浏览器缓存，结果标签页还是显示一个默认的地球图标，或者干脆啥都没有。打开 DevTools 检查 DOM 树，发现这个标签安安静静地躺在 <body> 里面。破案了，这就是问题根源。
快速修复方案：挪到 head 里去
打开你的 HTML 文件，把 body 里的 favicon link 标签剪出来，粘贴到 <head> 元素内部。完事儿。刷新浏览器，图标立马就出来了。
<!-- 错误写法：浏览器直接忽略 -->
<body>
<link rel='icon' href='/favicon.ico'>
<h1>My Website</h1>
</body>
<!-- 正确写法：放在这里 -->
<head>
<link rel='icon' href='/favicon.ico'>
</head>浏览器为什么无视 body 里的标签
HTML 规范写得很明确：<link> 元素只能放在 <head> 里。虽然现代浏览器对各种奇葩 HTML 写法都有很强的纠错能力，但一旦在 body 里碰到资源引入标签，解析器的行为就开始变得不可预测。
解析器会强制中断 body 渲染
当浏览器的 HTML parser 在 body 里撞见 <link> 标签时，通常会把该标签强行挪到 head 里。但如果你的 JavaScript 框架是在页面加载完成后动态注入这个标签，浏览器就不会重新触发图标请求。标签页自然就一直空白。
FOUC（无样式内容闪烁）问题
如果 favicon link 解析得太晚，浏览器可能在图标下载完成之前就先把标签页渲染出来了。你会看到一个空白标签页闪一下，然后图标才慢吞吞地加载出来。这种体验很糙。
实战参考：GitHub 是怎么做的
扒一下 GitHub 的源码看看。他们把所有图标相关的逻辑都死死摁在 <head> 里面。一个标准的 ICO 兜底，一个给现代浏览器的 SVG，再加一个 Apple Touch Icon。他们绝不会把这些标签散落到 DOM 各处。因为严格的标签位置能避免渲染竞态条件。照抄作业就行了。
2026 年的避坑指南
用框架的开发者特别容易踩这个坑，因为组件化写法容易让人顺手把 link 标签塞进 layout 组件里。几个防止翻车的建议：
- 用框架的 metadata API： Next.js、Remix、Astro 都提供了专门的 metadata 导出机制。用这些规范 API，别手动往 layout 组件里塞标签。可以看看我们的 Next.js favicon 配置指南，专门讲 App Router 下的处理方式。
- 定期审查 DOM： 用 Mzu favicondl 工具跑一下你的站点验证。如果需要参考标准实现，可以 下载 favicon 看看大厂是怎么组织 head 结构的。
- 别再用 React Helmet 注入静态图标： 到了 2026 年，用 JavaScript 动态注入静态 favicon 标签已经是反模式了。直接在 head 文档里写死原始 HTML。
图标该放哪就放哪。head 存放元数据，body 承载页面内容。守住这个边界，你的浏览器标签页就不会出幺蛾子。