你上传了一张精美的 512×512 图标到网站,但浏览器标签栏里依然是一团模糊的马赛克。问题不在文件不够大——而是缺少一个把 16、32 和 48 像素三种尺寸打包进同一个容器的 favicon ICO。

这个 .ico 文件做的事情,是大多数开发者从未想过的:它把浏览器在各种场景下需要的精确像素网格一次性给齐。标签栏要 16×16,Hi-DPI 屏幕要 32×32,Windows 任务栏和跳转列表要 48×48。如果你只提供一种尺寸,操作系统会帮你缩放——通常缩得很烂。

ICO 文件里「多尺寸」到底意味着什么

ICO 文件是一个容器,不是一张图片。可以把它理解成一个 zip 压缩包,里面装着几张 PNG 或 BMP 帧,每一帧都标注了自己的尺寸。HTML 规范在 rel='icon' 中定义了浏览器发现并请求这些资源的标准方式。

当你把 16、32 和 48 三种尺寸打包进一个文件,就相当于用一次 HTTP 请求给了浏览器三个选项。它会挑选最接近当前渲染场景的那个——无需缩放、无需抗锯齿、不会出现像素糊成一团的情况。

为什么偏偏是这三个尺寸?

每个数字都对应一个真实存在的 UI 展示场景:

少了 16,标签就模糊;少了 32,Retina 标签就模糊;少了 48,桌面快捷方式就糊成像素块。这三个尺寸恰好覆盖了最常见的三种渲染场景,又不会为没人请求的帧浪费字节。

浏览器如何选择渲染哪一帧

现代浏览器在处理包含多尺寸的 ICO 时遵循一套可预测的优先级:

  1. 检查 link 标签中是否有与渲染场景精确匹配的 sizes 属性。
  2. 在 ICO 容器中扫描与目标场景尺寸完全一致的帧。
  3. 若没有精确匹配,则选用最大的可用帧并下采样。
  4. 作为最后手段,退回到最近邻插值缩放。

Chrome 和 Firefox 在 Hi-DPI 屏幕上倾向于选最大的可用帧然后下采样,Safari 则常常直接挑像素数完全一致的那一帧。这就是为什么一个同时包含 16、32、48 的文件,在不同浏览器里都比包含 16、24、64 的文件看起来更清晰——浏览器几乎不需要再缩放。

为 16 像素约束做设计

16×16 的图标只有 256 个像素来传达你的品牌。这相当残酷。诀窍是 先抓轮廓,永远不要堆细节:

32 和 48 尺寸宽容得多,但它们应该看起来是同一个图标的高保真版本,而不是另一张不同的画。先做 16×16 设计再向上放大——如果 32 版本需要补充新细节,那说明你最初的 16 设计可能就太空了。

构建容器:一个可落地的方案

大多数现代工具,包括 Mzu favicondl 中的多尺寸 ICO 构建器,都允许你上传一张高清 PNG,然后导出包含你指定尺寸的容器。一份最小的 HTML 配置长这样:

<link rel='icon' href='/favicon.ico' sizes='16x16 32x32 48x48'>
<link rel='icon' type='image/svg+xml' href='/icon.svg'>
<link rel='apple-touch-icon' sizes='180x180' href='/apple-touch-icon.png'>

sizes 属性只是一个提示,并非强制要求——浏览器会解析 ICO 内部实际的帧来挑选最合适的。带上它有助于校验工具和辅助功能工具核对你的意图。

常见的坑

即便是经验丰富的开发者也会栽进下面几个坑:

如果你想在构建完成后进一步把文件压小,可以参考我们的 favicon ICO 体积优化指南。

收个尾

16、32、48 这三个尺寸的组合并非随意拍脑袋——它精确对应了最重要的三类渲染场景:标准标签、Hi-DPI 标签、桌面任务栏。把它们打包进一个 ICO,就能用一次 HTTP 请求覆盖现实里大约 95% 的 favicon 请求。再加一个 SVG 作为现代浏览器的后备、一个 Apple Touch Icon 应对 iOS,无论 OS 怎么折腾,网站图标都稳得住。