你把新的 SVG favicon 推送上线。Chrome 桌面端看起来很完美，结果 Slack 上有用户丢来一张 Safari iOS 的截图——你的标签页只剩一片空白的白色方块。"在我机器上没问题"和"到处都正常"之间的这道鸿沟，正是 favicon 兼容性测试要解决的问题。
一次 favicon 兼容性测试远不止"看上去对不对"。它是一套结构化的审计流程，需要对照浏览器、操作系统、搜索引擎实际发起 favicon 请求的每一个环境来验证你的图标栈。普通的 favicon 检测工具和真正的兼容性测试，差别在于覆盖范围——格式、尺寸、场景、渲染模式都得照顾到。
兼容性测试到底测什么
大多数开发者以为"兼容性"就是"能不能显示出来"。真正的兼容性至少覆盖五个维度，漏掉任何一项都会在生产环境留下一个悄无声息的故障：
- 格式兼容性 —— SVG、PNG、ICO 以及遗留的 GIF 在不同浏览器下表现各异。
- 分辨率兼容性 —— 16x16、32x32、48x48、96x96、180x180、192x192、512x512 各自对应不同的使用场景。
- 使用场景兼容性 —— 浏览器标签页、地址栏、书签栏、Pinned Tab（Safari 固定标签）、主屏幕、Google 搜索结果。
- 主题兼容性 —— 浅色模式、深色模式，以及 Safari 的彩色标签页。
- 抓取兼容性 —— Googlebot 能否从稳定的 URL 真正拿到你的图标文件。
每个维度的失败模式都不一样。ICO 文件如果超过 256KB，在 Safari 上就会出问题。SVG favicon 在 Chrome 里会渲染成纯色，但只有写法正确时才会响应 prefers-color-scheme。WHATWG 规范定义了带显式尺寸提示的 rel='icon'——浏览器据此选择合适的文件（WHATWG HTML Living Standard）。
用 Mzu favicondl 运行兼容性测试
Mzu favicondl 把兼容性测试看作一个分层的工作流，而不是一张截图。你贴一个 URL，工具就会把站点暴露的所有图标文件都拉下来——HTML 的 <link> 标签、根目录的 /favicon.ico、site.webmanifest，以及 Apple Touch 引用。然后你可以在浏览器实际使用的场景中逐一检查每个文件。
测试流程分三步：
- 清点 —— 收集站点提供的所有图标文件，包括 manifest 里藏着的那些。
- 渲染检查 —— 在关键尺寸（16、32、48、96、180）下预览每个文件。
- 格式转换 —— 生成缺失的格式（用 SVG 转 ICO、用 ICO 转 PNG），补齐图标栈里的缺口。
之所以要分阶段，是因为大多数兼容性问题不是渲染 bug，而是文件缺失。一个站点可能声明了 rel='icon' type='image/svg+xml'，但实际返回 404，结果 Safari 完全拿不到图标。Mzu favicondl 的清点步骤会立刻把这些缺口暴露出来。
参考 HTML 模板
下面是通过下方兼容性矩阵所需的最简 HTML link 标签模板，放到 <head> 里即可：
<link rel='icon' href='/icon.svg' type='image/svg+xml'>
<link rel='icon' href='/icon-96.png' sizes='96x96' type='image/png'>
<link rel='icon' href='/favicon.ico' sizes='32x32'>
<link rel='apple-touch-icon' href='/apple-touch-icon.png' sizes='180x180'>
<link rel='mask-icon' href='/safari-pinned.svg' color='#1a1a1a'>
<link rel='manifest' href='/site.webmanifest'>你应该参照的兼容性矩阵
一次聚焦的 favicon 兼容性测试不需要覆盖所有出厂过的设备，而是要覆盖现代浏览器实际使用的界面。下面是我们建议每次上线前都过一遍的矩阵：
| 使用场景 | 最低要求文件 | 常见失败原因 |
|---|---|---|
| 浏览器标签页（Chrome、Firefox、Edge） | SVG 或 32x32 PNG | link 上缺少 sizes 属性 |
| 浏览器标签页（Safari） | SVG 或 32x32 PNG | ICO 文件超过 256KB |
| 地址栏 | 16x16 PNG 或 ICO 内嵌条目 | 没有提供多尺寸 ICO |
| Pinned Tab（Safari 固定标签） | 单色 SVG | 误用全彩 SVG |
| 添加到主屏幕（iOS） | 180x180 PNG | 透明背景（iOS 会填充白色） |
| 添加到主屏幕（Android） | 192x192 + 512x512 maskable | 缺少 maskable 安全区 |
| Google 搜索结果 | 可抓取、正方形、≥48x48 | CDN 屏蔽了 Googlebot |
如果你的图标栈在任意一行有缺口，那恰好就是兼容性测试会失败的地方。修复办法通常是单次格式转换——这正是 Mzu favicondl 直接处理的环节。
让兼容性测试一次通过的实战建议
有三种写法几乎注定会让兼容性测试翻车，而且完全可以避免。
不要用不同 sizes 重复声明同一个 SVG。 <link rel='icon'> 上的 sizes 属性是个提示，不是开关。SVG 本身是分辨率无关的，浏览器会忽略这个属性。按照 WHATWG 规范，正确声明可缩放图标的方式是加 sizes='any'。
深色模式要在上线前测，而不是上线后。 透明背景的 SVG 上画个黑色 logo，在 Chrome 的深色标签栏里几乎看不见。Mzu favicondl 支持把 SVG 放在浅色和深色背景上并排预览。如果对比度不够，就要在 SVG 内部加一条 prefers-color-scheme 媒体查询。
始终包含一个多尺寸 ICO。 即便在今天，浏览器、爬虫、老版本 RSS 阅读器仍然会请求根目录下的 /favicon.ico。一个包含 16、32、48 像素条目的多尺寸 ICO，就能用一个文件覆盖所有遗留场景。
如果你想深入了解图标栈到底需要哪些文件，可以看我们的 2026 favicon 审计清单。如果你即将部署新图标，想在视觉上逐一确认每个浏览器场景，全浏览器 favicon 测试器 会带你走完整个工作流。
总结
favicon 兼容性测试关心的不是你笔记本上的图标能不能正常显示，而是每一种浏览器、操作系统、搜索引擎、渲染模式能否拉取、解析并展示正确的文件。把它当作格式、分辨率、场景、主题、抓取这五个维度的审计，把"凭感觉"变成"按清单核对"。Mzu favicondl 提供清点和转换流水线，你要做的就是在每次部署前逐行走完这张矩阵。