dns-prefetch 不加速首屏资源，仅对后续真实跨域请求有效，通过提前解析域名并缓存ip来节省20～100ms，但需确保href为协议相对域名、位置靠前、且仅用于确定会使用的第三方域名。
dns-prefetch 不加速首屏资源，只对后续真实发起的跨域请求有效——它提前把域名解析成 IP 地址并缓存，等 JS 中 fetch()、懒加载图片、字体 CSS 加载时直接跳过 DNS 查询阶段。效果通常省下 20～100ms，但前提是写对位置、格式和域名。
href 必须是协议相对域名，不能带路径或协议头
浏览器只从 href 中提取主机名，其余内容全被忽略。写错就静默失效，控制台不报错、Network 面板没记录，极难排查。
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn.example.com"> - ✅ 可接受（HTTPS 页面更稳）：
<link rel="dns-prefetch" href="https://fonts.googleapis.com"> - ❌ 错误：
<link rel="dns-prefetch" href="https://cdn.example.com/js/app.js">（含路径） - ❌ 错误：
<link rel="dns-prefetch" href="http://api.example.com">（HTTPS 页面大概率跳过） - ❌ 错误：
<link rel="dns-prefetch" href="cdn.example.com">（缺//，被当成本地路径）
必须放在 靠前位置，早于首个外部资源
浏览器流式解析 HTML，一读到 <link rel="dns-prefetch"> 就立即排队执行 DNS 查询。放晚了，相关请求早就发出去了。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- ✅ 推荐顺序：
<meta charset>→<title></title>→<link rel="dns-prefetch">× N → 首个<link rel="stylesheet">或<script src="https://..."></script> - ❌ 无效位置：塞在
里、包在<template></template>中、用 JS 动态创建并插入 - ⚠️ 即使位置正确，若前面堆了大量阻塞渲染的 CSS/JS，DNS 查询可能被首屏关键资源抢占调度优先级，Safari 尤其保守
只加确定会用的第三方域名，别碰同源或备用链
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。乱加不仅白耗资源，还可能挤占真实请求队列。
- ✅ 值得加：
//cdn.example.com（首屏图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 已缓存）、//admin.example.com（子域共享主域 DNS 缓存）、//ad.doubleclick.net（不稳定、常被拦截） - ⚠️ 多子域 CDN（如
//img0.cdn.com和//img1.cdn.com）仅当它们由不同权威 DNS 管理且被首屏资源分别引用时才需都加；否则加一个就够了
验证是否生效不能只看代码写了没
最可靠的方式是打开 DevTools 的 Network 面板，筛选出目标域名的请求，点开看 Timing 标签页里的 “DNS Lookup” 时间是否明显缩短（比如从 80ms 降到 0ms）。如果没变，大概率是位置错了，或者该域名压根没在后续 JS 或懒加载中真实发起请求。
- ⚠️ 注意：uBlock Origin 等广告拦截扩展会主动屏蔽
dns-prefetch请求，实测前建议禁用 - ⚠️ 它不保证执行——浏览器空闲时才做，弱网或内存紧张时可能直接跳过
- ⚠️ 如果目标域名只支持 HTTPS，而当前页是 HTTP，
//写法会降级为 HTTP 导致后续请求失败；这种场景应改用<link rel="preconnect">并显式声明crossorigin
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
