preload是强制高优先级加载当前页关键资源，解析到即发起请求；prefetch是低优先级预取后续页资源，仅空闲时加载，不提升当前页性能。
rel="preload" 和 rel="prefetch" 的行为差异
这两个值都用于资源预加载，但触发时机和用途完全不同。preload 是强制性、高优先级的当前导航资源获取，浏览器必须在解析到该 <link> 时立即发起请求；而 prefetch 是低优先级、可延迟的后续导航资源预取，通常在空闲时才执行，且可能被浏览器忽略（尤其在移动端或节电模式下）。
常见错误是把 prefetch 当作“提前加载首屏图片”用——它不会提升当前页性能，只服务于用户下一步可能的操作。真正要优化首屏关键资源（如字体、关键 CSS），必须用 preload 并配好 as 属性：
<link rel="preload" as="font" type="font/woff2" href="main.woff2" crossorigin>
漏掉 as 会导致浏览器无法正确设置请求优先级和 CORS 行为；漏掉 crossorigin 加载字体时会失败。
rel="dns-prefetch" 和 rel="preconnect" 的实际效果
两者都用于减少网络延迟，但粒度不同：dns-prefetch 只做 DNS 解析，preconnect 还会完成 TCP 握手和 TLS 协商（如果适用）。在现代浏览器中，preconnect 效果更直接，但开销也更大——它会真实建立连接，而 DNS 查询几乎无成本。
使用建议：
- 对 CDN 域名（如
cdn.example.com）优先用preconnect，尤其当页面会加载大量静态资源时 - 对第三方统计、广告等非关键域名，用
dns-prefetch更稳妥，避免过早占用连接池 - 不要对同个域名同时写
dns-prefetch和preconnect，后者已包含前者功能
典型写法：
<link rel="preconnect" href="https://fonts.googleapis.com">
rel="canonical" 和 rel="alternate" 在 SEO 场景中的误用
canonical 不是“推荐版本”，而是明确告诉搜索引擎：“这个 URL 才是唯一权威源，其他所有重复页面请合并索引”。一旦设错，可能导致整站内容被降权。而 alternate + hreflang 是成对出现的多语言声明，必须双向一致：A 页面声明 <link rel="alternate" hreflang="en" href="a-en.html">，B 页面就必须有对应反向链接。
容易踩的坑：
- 用
canonical指向一个 404 页面，或指向与当前页内容明显不匹配的 URL - 在分页列表页（如
/blog?page=2）上把canonical指向第一页，这会丢失分页内容的独立索引 -
alternate缺少hreflang，或hreflang值不符合 BCP 47 标准（如写成zh-CN正确，zh_CN或chinese无效）
rel="icon" 的多尺寸适配与兼容性陷阱
现代浏览器支持多种尺寸的 icon，但行为不统一：sizes 属性只对 rel="icon" 有效，对 rel="apple-touch-icon" 无效；iOS 仍依赖专用的 apple-touch-icon 链接，且不读取 sizes 中的逗号分隔列表（必须单个 <link> 标签声明一个尺寸）。
可靠写法是分开声明：
<link rel="icon" sizes="16x16" href="/favicon-16.png"><br><link rel="icon" sizes="32x32" href="/favicon-32.png"><br><link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
注意：rel="icon" 默认类型是 image/x-icon，但现代项目更常用 PNG；若用 PNG，务必显式声明 type="image/png"，否则旧版 Safari 可能忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
