dns-prefetch写了没效果，大概率因href格式错误（如含路径、协议或缺//）或位置不当（未置于最前，即和后、首个外链资源前）；浏览器静默忽略，不报错。
dns-prefetch 为什么写了没效果？
写了 <link rel="dns-prefetch"> 却没看到 DNS 时间下降，大概率是格式或位置错了。它不报错、不警告，静默失效是常态。
-
href必须只含//cdn.example.com这类协议相对写法；带https://或路径（如//cdn.example.com/js/app.js）整条标签被忽略 - 必须放在
最前面：<meta charset>→<title></title>→<link rel="dns-prefetch">× N → 首个<link rel="stylesheet">或<script></script> - 塞进
、用 JS 动态插入、包在<template></template>里，浏览器根本不解析
preconnect 和 dns-prefetch 到底该选哪个？
不是“都加更保险”，而是成本差异极大：一个只查 DNS，一个真建连接。选错会抢资源、拖首屏。
- 确定 1–2 秒内必用的跨域资源（如字体、首屏图片、核心 SDK），且域名支持 HTTPS → 用
<link rel="preconnect">，并带上crossorigin（哪怕同源，Safari 也认这个） - 只是“可能用到”或用户触发后才发请求（如分享按钮调用微博接口、埋点备用域名）→ 用
<link rel="dns-prefetch">，开销低、无连接占用 - 同一域名同时写两者，
preconnect会覆盖dns-prefetch，后者白加
字体加载卡顿，preload 为什么没用？
<link rel="preload"> 只是“提前拉文件”，不等于“能用”。字体这类跨域资源，漏掉任一环节就 fallback 到系统字体。
- 必须加
as="font"—— 写成as="fetch"或漏掉，浏览器当普通二进制处理，不进字体加载管线 - 必须加
crossorigin—— 字体默认走 CORS，不加该属性，Chrome/Firefox 直接丢弃 preload 响应 - CSS 中
@font-face规则里必须设font-display: swap—— 否则即使文件已缓存，文本仍白屏等待渲染 - 别 preload 所有字重：只预加载首屏实际用到的，比如
Inter-Regular.woff2，而非整套变体
怎么验证预解析是否真起作用？
不能靠代码写了就信，得看网络时间线。DevTools 里找对地方，否则容易误判。
- Chrome DevTools → Network 面板 → 筛选
Other类型 → 找目标域名的真实请求（如inter.woff2）→ 看domainlookupStart到domainlookupEnd是否接近 0ms - 更直接：地址栏输入
chrome://net-internals/#dns→ 刷新页面 → 搜索目标域名，看是否有缓存命中记录 - 注意：Safari 对
dns-prefetch更保守，常延迟执行；preconnect在弱网下可能因超时关闭连接，实际复用率不如预期
rel="preconnect" 都在消耗浏览器连接池，每个 href="//xxx" 都是一次真实 DNS 查询。错配比不写更伤。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
