WebClip图标不依赖sizes属性，iOS/macOS仅按文件名和真实像素尺寸匹配PNG图标，必须确保href指向的PNG文件实际尺寸精确匹配设备需求，且服务器返回正确MIME类型。
WebClip图标根本不用sizes属性
iOS/macOS 的 WebClip 图标（也就是添加到主屏幕后显示的图标）只认 rel="apple-touch-icon"，而且 sizes 在这个场景下只是冗余标注，Safari 不拿它做选择依据。你写 sizes="180x180"，浏览器照样只看文件真实像素尺寸和 href 路径是否匹配。
常见错误是把桌面 favicon 那套逻辑套过来：以为多写几个 sizes 就能自动适配 iPhone、iPad、Mac。实际 iOS 完全不解析 sizes 值，只按固定规则查找：
- 如果没指定
href，Safari 会依次尝试请求apple-touch-icon.png、apple-touch-icon-180x180.png等命名约定文件 - 一旦找到第一个能加载成功的 PNG 文件（无论尺寸），就直接用它，不验证是否真为 180×180
- 哪怕你写了
sizes="180x180"但文件其实是 120×120，iOS 也照用不误，结果就是模糊
真正起作用的是文件名和真实尺寸
iOS 只信任两件事：文件是否在根目录（或指定路径）、文件头里写的宽高是否精确匹配声明的设备需求。所谓“180×180”，指的是 PNG 文件本身的像素尺寸，不是 CSS 宽高，也不是 sizes 属性值。
必须确保：
立即学习“前端免费学习笔记（深入）”；
-
href指向的 PNG 文件，用图像编辑器或命令行工具确认过真实尺寸是 180×180 —— 不是导出时设了“180px 宽”就完事，得打开文件属性或用file icon-180x180.png验证 - 不要依赖 ICO 文件：iOS 完全不支持
.ico格式，rel="apple-touch-icon"必须指向 PNG 或 SVG（但 SVG 支持有限，推荐 PNG） - 多个尺寸要分开声明：
<link rel="apple-touch-icon" href="/icon-180.png">和<link rel="apple-touch-icon" href="/icon-167.png" sizes="167x167">是并列关系，但 Safari 实际只取第一个成功加载的，顺序不改变匹配逻辑
Android PWA 图标靠 manifest.json，不是 link 标签
如果你的目标是 Android 设备添加到主屏幕后的图标，<link rel="icon"> 里的 sizes 依然无效。真正起作用的是 manifest.json 里的 icons 数组：
{"src": "icon-192.png", "sizes": "192x192", "type": "image/png"}
注意这里 sizes 是 JSON 字段，且会被 Chrome/Edge 实际读取并用于匹配。但前提是：
- 页面已通过 HTTPS 提供
-
<link rel="manifest" href="/manifest.json">已正确声明且返回 200 - 对应 PNG 文件真实尺寸必须严格等于
sizes字段值，差一个像素都会被跳过 - 不能只靠 HTML 里的
<link rel="icon">，没有 manifest，Android 不会显示 PWA 图标
调试时别信 HTML 源码里的 sizes 值
最可靠的验证方式只有两个：
- 在 iOS Safari 中打开页面 → 添加到主屏幕 → 截图看图标是否清晰；再进设置 → 主屏幕 → 查看图标实际渲染效果
- 用 macOS Safari 的 Web Inspector → 开发 → 显示 JavaScript 控制台 → 刷新页面后看 Console 是否报
Failed to load resource: the server responded with a status of 404，对应你写的href路径 - 千万别用 Network 面板过滤
favicon来判断 WebClip 加载——iOS 根本不会发那个请求，它走的是独立资源发现机制
容易被忽略的硬约束：WebClip 图标没有 fallback 机制。写错路径、尺寸不匹配、MIME 类型不对（比如服务器返回 text/plain），iOS 就直接回退到网页截图，而不是换下一个 <link>。
