一个网站的图标问题，常常不是没有图片，而是图片没有放对地方。首页左上角已经换了新角色，文章页仍然显示模板图标；浏览器标签里是旧文件，手机桌面上的入口又被裁掉半张脸。开发者看到的 logo.png 只有一个名字，用户看到的却是几个不同入口。
IP as Logo可以为角色设计提供 Skill，也提供现成素材库。但拿到一张方形图片之后，网站接入仍然是一项独立工作：整理源文件、导出尺寸、声明用途、处理裁切，再检查真实页面。
图片生成和网站配置要分开
这个项目的仓库主要是说明文档与示例素材，不是运行在服务器上的图片服务。使用 Skill 需要兼容智能体和可调用的图像生成能力。它不会自动修改网站的 HTML，也不会替你生成适合所有设备的图标套装。
这意味着，不论图片来自图库还是生成，都应该先建立一份正式源文件。源文件不直接被所有页面使用，而是作为后续尺寸、留白和格式处理的起点。
源文件选定后，先确认它是什么：位图还是矢量、是否自带背景、像素尺寸多大、边缘是否已经裁切。不要只看扩展名，更不要把 PNG 改名为 SVG 后认为已经矢量化。需要矢量输出，应另外整理实际路径与形状。
对于角色式图形，检查角落构图尤其重要。人物从下角冒出来，大图里很鲜明，但如果脸已经贴住边缘，手机平台再施加遮罩时，就没有调整空间。
项目展示图提供的是角色方向。网页图标的格式、声明和安全区域，还需要在接入时单独处理。
先列出入口，再决定导出文件
常见的入口至少有四个：导航栏中的可见标识、浏览器标签、手机桌面入口、社交分享卡片。它们的显示形状和信息量不同。
导航栏通常将图形与站名并排，图形需要让文字留有空间。标签图标非常小，主要依赖轮廓和颜色。手机入口可能被平台裁切，需要留出安全区域。社交卡片往往是横向画面，还需要标题与主题信息。
不要用一张横向封面去做 favicon，也不要把 32 像素的小图放大作为分享封面。前者会被缩成难以辨认的细条，后者会明显模糊。尽管它们表达同一个站点，也应该从源图分别制作。
一份静态站的目录示例：
public/
brand/
site-mark.png
favicon-32.png
favicon-64.png
apple-touch-icon.png
app-icon-192.png
app-icon-512.png
app-icon-maskable-512.png
share-card.png
site.webmanifest
这里的文件名与尺寸是一种组织方式，不是所有网站都必须完整使用。没有 PWA 的站点，不必为了凑齐列表添加无用的安装入口。已有框架自动处理图标时，也应优先遵循框架当前文档。
普通网页的图标声明
对于由自己控制 <head> 的网页，可以通过 link 指定图标。例如：
<link rel="icon" type="image/png" sizes="32x32"
href="/brand/favicon-32.png">
<link rel="icon" type="image/png" sizes="64x64"
href="/brand/favicon-64.png">
<link rel="apple-touch-icon" href="/brand/apple-touch-icon.png">
这些路径是示例，使用前必须对应到实际部署的文件。sizes 描述图片尺寸，type 描述媒体类型，浏览器会参考这些信息选择资源，而不是因为文件名包含 favicon 就自动理解所有用途。
MDN 的 rel 文档说明了图标选择机制，也指出 iOS 的 Web Clip 使用不同入口。添加桌面图标与浏览器标签图标要分别考虑。
如果主题模板已经输出 rel="icon"，先查看生成后的 HTML。重复声明不同文件，可能让实际选择与预期不一致。修改模板源文件以后，也要确认构建产物包含新声明，而不是只在开发环境看到了新图。
导航栏中的图形是另外一个普通图片元素，例如：
<a href="/" aria-label="返回首页">
<img src="/brand/site-mark.png" width="32" height="32" alt="">
</a>
这是只有图形作为首页入口时的一种写法。若链接内部同时有可见站名，可让文字承担名称，避免重复的替代文本。具体应按实际结构处理，而不是把示例里的标签机械复制到所有位置。
PWA 图标写在哪里
提供 PWA 的网站，通常通过 Web App Manifest 声明应用信息与图标：
{
"name": "Example Notes",
"short_name": "Notes",
"start_url": "/",
"display": "standalone",
"icons": [
{
"src": "/brand/app-icon-192.png",
"sizes": "192x192",
"type": "image/png",
"purpose": "any"
},
{
"src": "/brand/app-icon-512.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any"
},
{
"src": "/brand/app-icon-maskable-512.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "maskable"
}
]
}
页面再引用它：
<link rel="manifest" href="/site.webmanifest">
这段代码是配置结构示例，并不意味着添加它后就满足所有 PWA 安装条件。图标只是 Manifest 的一部分；应用行为与安装支持仍取决于浏览器和其他配置。
MDN 的 Manifest icons 文档解释了 src、sizes、type 与 purpose。这里把普通图标与遮罩图标分成两个文件，是为了让不同用途的留白可控。
没有专门整理遮罩图标时，不要简单把普通文件的 purpose 改成 any maskable。声明并不会改变图片里的角色位置。你说它可以被裁切，不等于它的关键部分真的在安全区域内。
角落构图怎样适配遮罩
IP as Logo 示例常见主体从下方角落进入画面的形式。它在方形卡片里有个性，但在手机入口里可能出现两个问题：顶部特征被裁掉，或者脸部重心偏得过远。
制作遮罩版本时，背景可以铺满画布，角色关键部分则向中心收一些。保留完整识别特征比维持原来的边缘接触更重要。导航栏版本与手机入口版本不必拥有完全相同的像素位置。
web.dev 对 maskable icon 的介绍给出了跨形状裁切的安全区域概念。你可以按圆形、圆角方形等遮罩预览自己的图，确认脸、耳朵或主要特征没有损失。
普通头像也会裁成圆形，检查方式类似。不过圆形社交头像与 PWA 遮罩并非同一套技术要求，不要只看某个平台头像正常，就认定手机入口一定没问题。
选图阶段就保留一些留白，后面的整理会更容易。如果原图关键部位已经被切掉，缩小主体只能把缺口一起缩小，无法恢复不存在的内容。
观察角色靠近边缘的位置。实际导出图标时，应根据入口的裁切方式重新安排留白。
把显示尺寸和文件尺寸分清
网页上显示为 32 像素，不一定应该只准备一张 32 像素的导航图片。高密度屏幕可能需要更高像素的资源，但文件也不应大到每次都下载几千像素的原图。
普通内容图片可以通过 srcset 等方式提供不同资源；一个很小的站点标识则更适合直接选用合理尺寸的文件，保持接入简单。根据实际使用位置做导出，不要为每个可能的尺寸复制几十份没人维护的文件。
HTML 中写明宽高，可以让页面提前预留空间。CSS 改变显示尺寸时，应保持宽高比例，不要让角色被拉扁。背景圆角也要确认由谁负责：素材本身、页面 CSS 或设备遮罩，尽量不要层层叠加。
位图导出需要查看边缘是否变糊。减少尺寸以后，细线和小眼睛可能消失，这属于设计与缩放共同作用的问题。单纯提高压缩质量，无法让原本过细的轮廓重新清楚。
文件能打开，不代表页面引用正确
部署以后，先直接访问图标路径。确认返回的是图片，而不是主题的错误页、登录页或重定向后的 HTML。某些静态服务会把不存在的路径回退到首页，看起来是 HTTP 200，却不是正确资源。
接着查看页面最终输出的图标声明。路径要对应当前域名与部署位置；如果站点部署在子路径下，根路径写法可能指向错误位置。主题设置页保存了路径，也不等于所有页面都已经引用它。
图标不应放在需要登录的管理目录，也不应依赖几分钟后过期的签名链接。用户和搜索爬虫需要能够长期访问。正式文件使用稳定地址，素材管理则保留自己的源文件和版本记录。
搜索结果里的图标有自己的规则
Google 的 favicon 文档要求首页与图标文件可以被抓取，图标为方形，建议使用大于 48 像素的资源，并保持地址稳定。符合要求不保证一定展示，也不保证更换后立即更新。
这里尤其容易照搬旧教程。有些文章把尺寸写成必须是 48 的倍数，读者又把那句话当成永久规则。配置前应看当前官方文档，不要为了旧说法反复改文件。
还要区分域名、子域名和子目录。搜索展示按主机名处理站点图标，不能因为在某个子目录配置了不同图片，就期待它一定有独立的搜索图标。
做好站内配置后，搜索变化需要另行观察。不要把缓存中的旧图当作图片生成失败，也不要为了催促更新每天更换地址。
分享封面与站点图标不要相互代替
分享卡片通常需要横向画面，图标通常需要方形。用同一角色可以保持归属，但页面声明应该指向各自的导出文件。给文章配置分享图时，还应确认主题文字没有被平台缩略图裁掉。
对于内容站，站点默认分享图与单篇文章封面也要区分。文章已有合适的封面，就让它表达文章主题；没有封面时，默认站点图可以提供稳定的视觉。不要让每一篇文章都显示同一张巨大 Logo，而标题又难以看清。
发布以后可以查看页面最终输出的社交元信息，确认图片 URL 为完整且可访问的公开地址。页面里看得到封面，不代表分享抓取端一定能访问同一个资源。图片鉴权、临时链接和错误 MIME 类型都可能使两者产生差别。
为下一次维护留下说明
一份简短维护文件可以记录入口、路径、尺寸、正式源图和部署方式。框架升级或主题更换时，先按它恢复应该存在的图标声明，再检查是否与新版自动生成的声明重复。
如果图片来自 CDN，也要记录本站页面如何引用它。域名、存储桶和公开路径调整时，图标可能不像正文图片那样容易被注意到，却会在浏览器标签和搜索里持续显示错误。
删除旧素材之前，检查页面、Manifest 和后台设置是否还有引用。不要仅凭文件名看起来旧就清理。归档原图与运行时清理是两件事，前者保留维护能力，后者则要确保没有在用的路径被移除。
更新与回退都要留一条路
替换前保留旧文件与当前声明，新版本放在明确位置。改完先看首页、文章页与移动入口，再确认不存在新旧混用。浏览器缓存可能暂时显示旧图，所以需要同时核对页面声明和实际请求。
站内资源可以通过版本命名管理，但搜索 favicon 又强调地址稳定。规划时可以给搜索图标保留固定路径，内部归档另存版本；页面其他素材的缓存策略则按自己的部署方式处理。不要一条规则套住所有图片。
如果新图确实存在裁切或可读性问题，恢复旧声明比临时重画更快。等新版本整理好再替换，用户不会看到半套图标。
这类工作适合写一张短清单：文件可访问、类型正确、页面声明一致、小尺寸可读、手机裁切安全、旧版本可回退。把这些环节完成后，角色图片才算真正进入网站，而不只是出现在素材文件夹里。