dns-prefetch 和 preload 的生效依赖严格的位置与属性规范：dns-prefetch 必须位于 <meta charset> 和 <title> 之后、首个外部资源之前，且 href 须为 // 开头的纯域名；preload 的 as 属性必须准确匹配资源类型（如字体用 as="font" 并加 crossorigin），否则降级为普通请求或被忽略。
预解析不是靠加标签就能生效的魔法，它依赖浏览器对 HTML 结构的流式扫描顺序和资源类型识别。放错位置、写错属性，dns-prefetch 和 preload 都等于没写。
dns-prefetch 必须放在 <meta charset> 和 <title> 之后、首个外部资源之前
浏览器是边下载边解析的，dns-prefetch 一旦被读到就立刻排队执行。如果它出现在第一个 <link rel="stylesheet"> 或 <script src> 后面，首屏资源请求可能已经发出去了，预解析根本来不及起作用。
- ✅ 正确顺序：
<meta charset="utf-8">→<title>→<link rel="dns-prefetch" href="//cdn.example.com">→<link rel="stylesheet" href="main.css"> - ❌ 错误做法：塞在
<body>里、用 JS 动态插入、包裹在<template>中 - ⚠️ Safari 更保守，常延迟到空闲或用户交互后才执行；放太晚，可能被 CSS/JS 抢占调度优先级
href 必须是 // 开头的纯域名，路径和端口会导致整个标签被忽略
dns-prefetch 只提取 href 中的主机名做 DNS 查询，其余内容全被丢弃。写错格式不会报错，但等于没写——你在控制台也看不到任何提示。
- ✅ 合法写法：
<link rel="dns-prefetch" href="//cdn.example.com">、<link rel="dns-prefetch" href="//fonts.googleapis.com"> - ❌ 非法写法：
href="https://cdn.example.com"（协议头多余）、href="//cdn.example.com/js/app.js"（含路径）、href="cdn.example.com:8080"（显式端口）、href="http:/cdn.example.com"（协议拼错） - ⚠️
//fonts.gstatic.com和//fonts.googleapis.com是两个独立域名，不能互相替代；也不支持通配符，//*.example.com无效
preload 的 as 属性写错，等于白加甚至引发重复请求
preload 不是“提前下载”那么简单，浏览器靠 as 值决定请求头、CORS 策略、缓存复用逻辑和优先级。漏写或错写，它就降级为普通 fetch，失去高优调度能力。
立即学习“前端免费学习笔记（深入）”；
- 字体必须写
as="font"+crossorigin：WOFF2 同源也强制要求crossorigin，否则 Chrome 静默丢弃，控制台无报错 - CSS 必须写
as="style"：写成as="fetch"或不写，会导致与后续<link rel="stylesheet">重复下载 - JS 用
as="script"，但注意：它只下载不执行；若后续<script src="app.js">没加async或defer，仍可能因阻塞解析导致重复请求
验证是否真生效，不能只看代码写了没
光加标签不等于起作用。dns-prefetch 是提示，不是指令，浏览器有权忽略；preload 是否生效，得看 Network 面板里的真实行为。
- 查
dns-prefetch：打开chrome://net-internals/#dns，看对应域名是否已缓存；或在 Network 面板筛选Other类型，找domainlookup时间接近 0ms 的请求 - 查
preload：Network 面板中 Initiator 显示为preload、Priority 为Highest或High、请求时间早于自然发现且复用缓存 - ⚠️ 构建工具自动生成时，必须验证最终 HTML 中该标签是否落在
<meta charset>和首个<link rel="stylesheet">之间——否则等于没写
