<link>标签是HTML中唯一能主动干预浏览器资源加载时机与优先级的声明式控制点，决定首屏是否卡顿、LCP是否超限；它强制提前抓取资源，但若资源未被当前页使用或顺序冲突，会挤占带宽、延迟关键请求；仅对as属性明确匹配的类型生效（如as="script"对CSS无效）；预加载的script不自动执行，需后续<script src>引入；href资源已缓存时仍触发无意义HEAD请求；SSR中服务端preload与客户端动态插入重复可能引发双下载。
<link> 标签是 HTML 中唯一能主动干预浏览器资源加载时机与优先级的声明式控制点，不是“锦上添花”，而是决定首屏是否卡顿、LCP 是否超限的关键开关。
为什么 <link rel="preload"> 不能乱用
它强制浏览器提前抓取资源，但若目标资源实际不被当前页面使用，或加载顺序与执行逻辑冲突，反而会挤占带宽、延迟真正关键的请求。
- 只对
as属性明确匹配的资源类型生效（如as="script"对 CSS 无效） - 预加载的
script不会自动执行，仍需后续<script src>引入，否则白忙一场 - 若
href指向的资源已缓存，preload仍会触发一次无意义的 HTTP HEAD 请求（Chrome 表现） - 在 SSR 场景下，服务端输出的
preload若与客户端 hydration 时动态插入的资源重复，可能触发双下载
<link rel="preconnect"> 必须放在 <head> 最前几行
DNS 解析和 TCP/TLS 握手耗时不可忽略，尤其当页面依赖 CDN 或第三方 API 域名时。晚于关键 CSS 或 JS 的 preconnect 几乎无效。
- 只对跨域域名有效（同域 preconnect 无收益）
- 必须早于任何可能触发该域名请求的标签（比如
<img src="https://cdn.example.com/...">） - 不要为超过 3–4 个域名添加
preconnect，浏览器并发连接数有限，过多反而竞争阻塞 - 若目标域名支持 HTTP/2 或 HTTP/3，
preconnect收益下降，此时应优先考虑dns-prefetch
<link rel="prefetch"> 不等于“预加载下一页”
它只是提示浏览器在空闲时尝试获取资源，不保证下载完成，也不提升优先级。把它当成“用户大概率要点”的赌注，而不是确定性优化手段。
立即学习“前端免费学习笔记（深入）”；
- 仅适用于导航类跳转（如
prefetch下一页 HTML），对 JSON API 资源无效（浏览器不缓存） - 在移动弱网下常被浏览器直接丢弃，无法 fallback
- 若 prefetch 的 HTML 包含未内联的关键 CSS/JS，用户点击后仍要等二次渲染，体验无改善
- Next.js / Remix 等框架默认用更可靠的
Link组件 +prefetchprop 替代原生标签，因其可结合路由状态做条件触发
真正容易被忽略的是：所有这些 <link> 控制都依赖浏览器解析 HTML 的线性顺序。一个没加 charset 的 <head>、一段阻塞的同步脚本、甚至 <meta> 放错位置，都会让前面精心写的 preload 失效——因为浏览器根本来不及读到它。
