Favicon生成器一口气给你10个图标文件，真正决定搜索结果那个小方块的只有一张

摘要：这个工具最容易被误解的地方，是把生成10个文件当成了交付完成。实测下来，透明logo进去、出来的10张全是不透明白底；勾上那个圆角选项，反而会让iOS主屏图标出问题；而Google那边压根只按主机名认一张。

所以真正要你动手判断的不是点哪个按钮，是留哪张、改哪张、哪三张可以直接删掉。这篇把10个产物逐张拆开看，包括那个被认真手写出来的ICO二进制。

先把结论摆在前面：10个文件里真正上场的没那么多

网站图标这件事，看上去是所有SEO任务里最没技术含量的一项。找张logo，扔进生成器，下载，上传到根目录，收工。

但凡这么干过几次的人都知道，事情很少这么顺。标签页上那个小方块要么不出现，要么出现的是上一版logo，要么在深色模式下变成一块刺眼的白疙瘩。手机加到主屏，图标四角莫名其妙黑了一圈。这些症状的根子，多数不在浏览器缓存，而在生成那一步就已经埋下了。

Favicon生成器这款工具把一张图变成10个尺寸、3段配置代码，整个过程在浏览器里跑完，图片不上传服务器。这个基本盘是扎实的。这篇要拆的是基本盘之上的那层：它给你的10个文件，并不是10个都需要传；而它默认的处理方式，会在两个地方把你的图标改成你没打算要的样子。

这次实测是怎么做的

纯前端工具没有后端接口可打，curl打不出任何东西。所以这次全部走浏览器里的真实调用：构造已知内容的源图，喂给工具自己的regenerate()，再逐像素读回它生成的canvas。ICO那部分直接把工具产出的二进制字节拿出来，按格式手工解析每一个字段。

这种做法的好处是没有猜测成分。工具说生成了什么，和它实际生成了什么，中间那点差距会被像素和字节直接量出来。凡是下面出现的数字，都是从这次调用里读回来的，不是从说明文档里抄的。

10个尺寸的清单

这张表最后一列是这次实测数出来的，下面会讲怎么数的。先记住这个数字：10张里有3张，工具生成了，但它自己给的3段代码里一次都没提到过。

上传透明logo，拿回来的10张全是不透明的

这是本次实测里最该被写在工具页面上、却一个字都没写的一条。

实测过程与读数

构造一张512×512的源图：整块画布clearRect清成全透明，中间画一个不透明的圆。读源图左上角像素，RGBA是0,0,0,0，确认透明通道正常。

把这张图喂给工具，不动任何选项（背景色默认#ffffff，圆角默认不勾），跑它自己的生成函数，然后逐张读回来：

最后一行的意思是：512×512那张图一共262144个像素，没有一个像素的alpha值不是255。透明通道被彻底抹平了。

为什么会这样

生成逻辑里，每张画布开工第一件事是拿背景色铺满整块区域，然后才把源图按覆盖模式画上去。源图不透明的部分盖住底色，透明的部分让底色透出来。结果就是不管你上传什么，出来的一定是一块实心的、四角带底色的方图。

而那个背景色输入框是个标准的取色控件。取色控件能表达任何颜色，唯独表达不了透明。也就是说，这个工具在设计上就没有留下产出透明图标的路径，无论你怎么点。

这不算实现失误，更像是一个没被想到的场景。工具页面上那行提示写着背景色是给透明图用的，字面意思是有透明区域才会用到它——读起来很容易理解成不透明的图就不会被填色。实际情况是每一张都填，只不过不透明的源图正好把底色全盖住了，你看不出来而已。

这件事会在哪里咬你

浏览器标签栏。Chrome和Edge的深色模式下，标签栏底色是深灰接近黑，你那张白底图标会变成一小块高亮的白方块，在一排图标里格外扎眼。书签栏、历史记录、新标签页的常用站点九宫格，同理。

现代做法是给favicon留透明背景，让它自己去适应明暗两套主题。更讲究一点的站会再补一张SVG图标，在矢量文件内部用媒体查询写两套配色，浏览器切到深色模式时自动换色。这两条路这个工具都走不了：前者它填色，后者它不生成SVG。

绕过去的办法只有一个，而且和这个工具没关系：拿它生成的PNG去任何支持透明的图像编辑器里，把那层底色抠掉再传。或者干脆自己按尺寸导出。它的价值在于告诉你需要哪些尺寸、以及那段HTML怎么写，不在于最后那张图能直接上线。

如果你的站本来就是浅色背景、logo也是深色的，那这个问题可以忽略——白底方块在浅色标签栏上不明显。真正难受的是深色品牌站和那些logo本身带彩色渐变的站，白底会把整个图标的边界硬生生框出来。

圆角那个勾选框，是唯一能把iOS图标弄坏的开关

这条稍微绕一点，但结论很干脆：不勾它，你的apple-touch-icon是对的；勾上它，反而错了。

勾上之后发生了什么

把圆角勾上重新生成，再逐张数全透明像素：

两件事同时冒出来了。

第一件：圆角只对128像素及以上的尺寸生效。阈值写死在代码里。所以同一套图标，16、32、48、64、96这5张是方角，128、150、180、192、512这5张是圆角。你以为在统一风格，实际拿到的是一半一半。

这个阈值本身有它的道理：16像素的图标切圆角，半径连4个像素都不到，切完只会让边缘发毛。但工具没有把这个规则说出来，界面上就是一个朴素的勾选框，勾上之后哪些变了哪些没变，只能自己一张张看。

第二件更要命：圆角是靠先清空画布、再按圆角路径裁剪、然后在裁剪区内填色实现的。裁掉的那部分不是白色，是全透明。apple-touch-icon那张180×180的图，四个角一共976个像素的alpha值是0。

iOS会怎么处理这四个透明角

两条广为人知的行为，恰好把这个洞踩穿：

其一，iOS不支持主屏图标的透明通道。带alpha的区域会被填成黑色，而不是透出壁纸。你精心切出来的圆角，到手机上变成四个黑角。

其二，iOS自己会给主屏图标套一层圆角遮罩。你预先切过一次圆角，系统再切一次，边缘会出现先内凹、再外凸、再内凹的怪异轮廓，业内管这个叫双重圆角。

这两条合起来的效果是：黑色的直角三角形出现在圆角外侧，而圆角本身还比正常的更深一圈。在浅色壁纸上尤其明显，四个角像被啃过。

所以这个开关的正确用法是：别碰它。不勾的时候，工具产出的是一张四角带白底的方图，这恰好就是Apple一直建议的做法——给一张不透明的方图，圆角交给系统。工具把这个默认值设对了，却提供了一个把它改错的按钮，还在说明里写着这是模拟iPhone主屏的实际显示效果。

这大概是整个工具里最有讽刺意味的一处：默认不动是对的，动一下就错了，而说明书鼓励你动。

历史包袱：precomposed那个后缀

顺便说清一个容易混的概念。早年iOS会主动给主屏图标加高光和圆角，所以出现了apple-touch-icon-precomposed这个变体，意思是这张图已经处理好了、系统别再动它。iOS 7之后系统不再加高光，这个变体的实际意义大幅缩水，但它仍然是Google认可的rel取值之一。

之所以提它，是因为有人看到圆角选项会联想到这个后缀，以为勾上圆角就该配precomposed。实际上这个工具生成的声明里只有普通的apple-touch-icon，不带后缀，两者并没有联动。

非正方形的logo进去，出来只剩中间那一块

说明里写了非正方形图片会居中裁切，这句话本身没错。但它没说会裁掉多少。

拿一张横版logo做实验

构造一张1000×250的宽图，模拟最常见的那种横版品牌标识：左端一块蓝色（图形符号的位置）、正中一块绿色、右端一块橙色（品牌英文名的位置），底色浅灰。

喂进去，读512×512那张产物的四角和正中：

左端的蓝和右端的橙，一个像素都没剩下。

算一下裁掉了多少

缩放比例取的是宽高两个方向里较大的那个，保证画布被填满。1000×250缩到512×512，纵向要放大2.048倍，横向跟着放大同样倍数，源图被拉成2048×512，然后从中间截512宽。

换算回源图坐标，保留下来的是横向375到625这一段，总宽度1000里只留了250，四分之三被切掉了。品牌名、图形符号，凡是不在正中间那25%里的东西，全部消失。

反过来也一样：竖版的长条图会被裁掉上下两头。工具用的是填满画布的策略而不是留白装下的策略，这两种做法各有各的场景，只是它没给你选。

该怎么办

先把logo自己裁成正方形再上传，而且是你自己决定裁哪一块，不是交给工具从中间硬切。横版标识通常只有图形部分适合当图标，文字部分在16×16上本来也糊成一团——那个尺寸下一个汉字大概占8个像素见方，比标点符号大不了多少。

做电商独立站的会更熟悉这个问题。产品图、社交卡片、图标，三种场景的安全区完全不同，一张图走天下的结果就是每个场景都缺一角。社交卡片那一侧的裁切规律，可以顺带看看Open Graph预览工具逐字段体检四大平台的社交卡片那篇里的四平台对照。

打包下载全部那个按钮，并没有打包

按钮上写着打包下载全部，后面还跟了个括号注明是ZIP。使用说明第3步也写着点它就能一次性下载所有图标文件。

页面上根本没有打包能力

查了三处，结论一致：

• 全局作用域里不存在任何ZIP打包库，常见的那个JSZip也没有
• 页面上的外链脚本只有两个：一个统计脚本，一个站点自己的增强脚本
• 那个函数的实现是把10个文件排成队列，每300毫秒触发一次下载，最后再补一次ICO

换句话说，点下去的实际效果是连续触发11次独立下载，总耗时3秒多。源码里那行注释写得很坦率，大意是就用简单办法，一个个下、中间加点延时。

这个差别会在浏览器那里体现出来

浏览器对同一个页面连续触发多文件下载是有防御的。Chrome会在地址栏弹一条询问，问你要不要允许这个站点下载多个文件。不点允许，你只会拿到第一个文件，然后就没有然后了。而按钮上写着ZIP，你会理所当然地去下载目录里找那个压缩包，找不到，再回来怀疑是不是工具坏了。

还有个副作用是文件名。11次独立下载各走各的，如果下载目录里已经有同名文件，浏览器会自动加序号后缀，变成favicon-16x16(1).png这种。传到服务器之前记得核对一遍文件名，带括号的那些HTML里可找不到。

知道真相之后用起来其实没问题：点一次，允许多文件下载，去下载目录里把11个文件收走。只是别指望有个压缩包在那儿等你。

说明书承诺的SVG声明，代码里一行都没有

工具的常见问题第5条讲SVG格式要不要生成，答案里有一句：本工具生成的HTML代码已包含SVG声明。

把生成的HTML代码取出来，去掉高亮标签转成纯文本，全文匹配svg三个字母，结果是零命中。整段代码15行有效行，引用了8个文件：

• favicon.ico、favicon-16x16.png、favicon-32x32.png、favicon-96x96.png
• apple-touch-icon.png
• manifest.json、mstile-150x150.png、browserconfig.xml

没有rel="icon" type="image/svg+xml"这一行，也没有任何SVG文件名。这条FAQ是纯粹的空头支票。

顺带一提，还有一条也对不上

使用场景第5条写着能生成Open Graph和Twitter Card所需的图标尺寸。翻遍那10个尺寸，最大的一张是512×512的正方形，社交卡片要的1200×630横图并不在其中。

这两条放在一起看，说明页那部分文案更像是按通用模板填的，没有跟着实现走。凡是说明书里出现的功能，在按下按钮之前最好先自己验一遍——这句话适用于任何工具，不只是这一款。

核实的成本其实很低。生成一次，把代码复制出来，搜一下那个关键词在不在。30秒的事，能省掉上线后对着一份不完整的head反复排查的两个小时。

10个文件里有3个，从来没人引用

把三段生成代码（HTML、manifest.json、browserconfig.xml）全部转成纯文本，正则抓出所有 .png和 .ico文件名，去重后和那10个产物一比：

• 被引用的8个：favicon.ico、favicon-16x16.png、favicon-32x32.png、favicon-96x96.png、apple-touch-icon.png、mstile-150x150.png、android-chrome-192x192.png、android-chrome-512x512.png
• 无人引用的3个：favicon-48x48.png、favicon-64x64.png、favicon-128x128.png

这里加起来是11不是10，因为favicon.ico本身不在那10张PNG里，它是工具额外拼出来的第11个产物。

这3个要不要传

48×48那张情况特殊：它的PNG文件确实没被任何代码引用，但它的像素数据被打进了favicon.ico里。所以那个 .png可以不传，它的内容已经藏在 .ico里了。

64×64和128×128就是纯粹多出来的两张。说明表格里给它们标了用途，一个写Windows快捷方式图标，一个写Chrome应用商店。这两个场景都不是浏览器读HTML时会去找的东西——快捷方式图标由系统从 .ico里取，应用商店的图标在开发者后台单独上传。放在网站根目录里，它们不会被任何东西请求到。

所以这一步的实际操作是：10个下载下来，传8个，删3个（48那张也可以留着备用，反正只有1KB左右）。少传两个文件不会让网站快多少，但根目录干净一点，下次改版的人不会对着3个没人用的文件发愣。

为什么工具要生成这三张

猜测的成分大一些：这10个尺寸看着像是从某份流传很广的图标清单里抄来的，那类清单往往把历史上出现过的所有尺寸都列一遍，不区分现在还用不用。而生成代码那部分是另外写的，只挑了真正需要声明的几个。两部分没对齐，就多出来3张。

唯一被认真对待的部分：那段手写的ICO二进制

批评了半天，得说句公道话。这个工具里有一块做得相当扎实，扎实到值得单独拿出来讲。

ICO是个需要手写的格式

浏览器的Canvas能直接导出PNG和JPEG，导不出ICO。要生成 .ico文件，只能自己按格式一个字节一个字节地拼：先是6字节的文件头，然后每个尺寸一条16字节的目录项，最后是每个尺寸的图像数据，而图像数据本身又是一个精简版的BMP结构。

这活儿容易写错的地方特别多，随便挑几个坑：BMP的像素行是自下而上排的、颜色顺序是蓝绿红不是红绿蓝、图像高度字段要写实际高度的两倍、还得给一段透明掩码留出位置。任何一处写反，文件都能生成，但浏览器要么显示空白要么显示乱码。

把它生成的字节拆开看

直接取出工具产出的ICO二进制，按格式逐字段解析：

最后一行是最能说明问题的：每条目录项的偏移量和长度首尾相接，最后一条正好填满整个文件，一个字节不多一个字节不少。这种自洽不是碰运气能碰出来的。

高度字段那条也值得单独说一句。ICO内嵌的位图要把高度写成实际值的两倍，因为格式规定像素数据后面还跟着一段等高的透明掩码。16那条写的是32，说明作者知道这个规矩。很多手写实现在这里直接写16，生成的文件在部分环境下会上下颠倒或者只显示一半。

由此看出的工具水位

所以这个工具的实际水位是：越靠近底层、越需要严谨的部分做得越好；越靠近文案和交互的部分越松。ICO编码器一丝不苟，而按钮上印着一个不存在的ZIP。

这个反差本身挺有意思。它提醒我们评价一款工具不能只看表层，也不能因为表层的毛病就否定全部。判断该不该用，要落到具体环节上——这一款的ICO你可以放心用，那10张PNG你得自己再过一遍。

浏览器对图标的缓存，比你想的顽固得多

这一节和工具本身无关，但它是换图标之后最高频的困惑来源，值得占一个位置。

为什么改完看不到变化

浏览器缓存favicon的策略和缓存普通图片不是一回事。普通图片跟着页面的缓存头走，图标却往往被单独存在一个长期存活的位置，有些实现甚至在你清空浏览数据之后还留着。

于是就有了那个经典场面：文件传好了，代码贴对了，无痕窗口里显示新图标，你自己的浏览器上还是旧的，同事的机器上也是旧的，你开始怀疑是不是CDN没刷新。

几个能真正验证的手法

• 直接在地址栏访问图标文件本身，比如你的域名/favicon.ico，看返回的是不是新图。这一步能把服务器和浏览器两侧的问题分开
• 给声明加个版本参数，比如在href后面挂?v=2。这是最直接的破缓存手段，代价是每次换图都得改一次HTML
• 用无痕窗口或者另一个从没访问过这个站的浏览器确认，排除本机缓存干扰

搜索结果那一侧的更新更慢，那不是缓存问题，是抓取频率问题。Google什么时候重新抓你的首页、什么时候刷新索引里那张图，不由你控制。这一步只能等，通常以天甚至周计。换图标之后当天就去搜索结果里找变化，多半只会白跑一趟。

路径前缀这个输入框，藏着一个收录层面的误会

工具提供了一个路径前缀输入框，默认是斜杠，提示写着可以填 /images/ 这样的值。填什么，生成的HTML里所有文件地址就带什么前缀。

先说一个纯技术的坑

实测四种填法：

第三行是要小心的。少打一个前导斜杠，出来的就是相对路径。这段代码贴到首页没事，贴到/blog/xxx.html这种深一层的页面，浏览器会去找/blog/assets/icons/favicon.ico，找不到就是404。工具不校验也不补这个斜杠，原样拼上去。

末尾斜杠倒是会自动补，前导斜杠不管——这种一头管一头不管的处理，比两头都不管更容易骗过人，因为你会以为它已经在帮你规范化了。

这类因为路径基准算错而导致的静默404，在站点体检里非常常见，排查手法可以参考死链检测工具一次揪出改版后全站404与重定向链那篇里的思路。

再说SEO那一侧

Google关于搜索结果里显示网站图标的公开文档，有一条经常被忽略：每个主机名只支持一个图标。子域名可以各有各的，但同一个主机下的不同子目录不能各用各的。

这条规则和路径前缀这个功能凑在一起，会产生一个具体的误会。有人会想：那我给博客目录配一套图标、给商城目录配另一套，用路径前缀分开生成不就行了。技术上你确实能让浏览器标签页显示不同图标，但搜索结果那一侧不会跟着变，Google只会认它抓到的那一个。

同一份文档里还有几条同样值得记住的：图标必须是1:1的方图，最小8×8像素，官方建议用大于48×48的尺寸以适应各种展示位；rel属性值认icon、shortcut icon、apple-touch-icon和apple-touch-icon-precomposed这几种；图标文件和首页都不能被robots规则挡住，Googlebot和图片爬虫都要能抓到。

爬虫进不去这一条，踩的人最多

有些站把整个 /assets/ 目录Disallow掉，图标正好放在里面，于是搜索结果里那个位置一直是灰色的默认图形，怎么改HTML都没用。工具生成的代码本身没问题，问题出在文件放在了爬虫进不去的地方。

排查这一条只要两步：拿robots规则对着图标的实际路径比一遍，再确认首页本身没被挡。注意图片爬虫和普通爬虫是两个身份，有些站的robots里单独给图片爬虫写了更严的规则，图标会一起被误伤。要顺手排查head区其他标记的完整性，可以配合页面结构分析工具揪出H1层级、图片alt与语义标签短板那篇的检查清单一起做。

那么这个工具到底该怎么用

把上面所有实测折成一份操作清单，按顺序做就行。

上传之前

先把logo自己裁成正方形，自己决定保留哪一块，别指望工具从中间硬切能切对。如果你的品牌标识是横版的，通常只取图形部分。源图给到512×512以上，这一点工具的提示是对的。

顺手把源图的边距留出来一点。图标在很多场景下会被系统再套一层遮罩或者缩到很小，主体元素贴着边缘的话，缩完只剩一团颜色。

生成的时候

圆角那个勾选框不要碰。背景色如果你的站是深色主题，可以改成和站点背景接近的颜色，至少在深色标签栏上不会突兀。想要真正的透明，这个工具给不了，得去别的地方处理。

下载之后

点打包下载全部，允许浏览器的多文件下载提示，然后去下载目录收11个文件。核对文件名有没有被加上重名序号，传8个上服务器，64×64和128×128可以直接删。

贴代码的时候

路径前缀记得带前导斜杠。那段HTML直接用没问题，只是要知道它没有SVG声明——如果你想要现代浏览器优先用矢量图标，得自己补一行指向svg文件的声明，放在其他icon声明之前。浏览器会挑它认识的第一个可用声明，顺序是有意义的。

上线之后

确认图标路径没被robots规则挡住。这一步花不了30秒，却能省掉几周的困惑。再直接访问一次图标文件本身，确认服务器返回的是新图而不是旧图。真要验证Google那边认没认，只能等它重新抓取首页，急不来。

保哥带过的几个出海站里，图标问题的排查时间中位数远高于它应有的水平。原因几乎都一样：大家默认这是个不会出错的环节，于是出错时最后才去查它。

常见问题解答

为什么上传的透明PNG生成出来变成白底了？

因为生成逻辑里每张画布都会先用背景色铺满，再把源图画上去。实测512×512那张产物的262144个像素中，alpha值不等于255的数量是0，透明通道被完全抹平。背景色控件是取色器，无法表达透明，所以这个工具没有产出透明图标的路径。需要透明背景就得拿产物去图像编辑器里再处理一次。

圆角选项到底该不该勾？

不该勾。勾上之后128像素及以上的5张会把四角切成全透明，apple-touch-icon那张有3.01%的像素alpha为0。iOS不支持主屏图标透明，会把这些区域填黑；而且系统自己会套一层圆角遮罩，预先切过的图会出现双重圆角。不勾时产出的方角不透明图，恰好是Apple建议的形式。

10个文件是不是都要上传到服务器？

不用。工具生成的3段代码里只引用了8个文件，favicon-48x48.png、favicon-64x64.png、favicon-128x128.png这3张从未被引用。其中48那张的像素已经打包进favicon.ico，另外两张对应的场景不通过网页HTML请求。传8个就够了。

点了打包下载全部为什么找不到ZIP压缩包？

因为它没有打包。页面上不存在任何ZIP库，那个函数是把11个文件排队、每隔300毫秒触发一次独立下载。浏览器通常会弹出是否允许下载多个文件的询问，不允许就只能拿到第一个。按钮上的ZIP字样与实现不符。

我给不同子目录配了不同图标，为什么搜索结果里没变？

Google的公开文档写明每个主机名只支持一个图标，子域名可以区分，子目录不行。浏览器标签页会按你HTML里的声明显示不同图标，但搜索结果那一侧只认一个。另外要确认图标文件和首页都没有被robots规则挡住，Googlebot和图片爬虫都需要能访问。

换了新图标，为什么浏览器上还是旧的？

图标的缓存策略和普通图片不同，往往被单独存放且存活很久，清空浏览数据都未必能清掉。先直接在地址栏访问图标文件本身，确认服务器给的是新图；再用无痕窗口验证一次，把浏览器缓存和服务器问题分开。实在急着看到变化，就在声明的地址后面挂一个版本参数。

生成的favicon.ico文件本身可靠吗？

这部分做得相当扎实。把产出的二进制逐字段解析，文件头类型标记、三条目录项的尺寸与位深、信息头长度、双倍高度字段、压缩方式、透明掩码区全部符合格式要求，而且每条目录项的偏移与长度首尾相接，最后一条正好填满15086字节的文件长度。这块可以放心用。

权威参考资料