dns-prefetch 的 href 必须为 //domain.com（协议相对纯域名）或 https://domain.com（HTTPS 页面显式写法），不可含路径、端口、协议头或参数；且必须置于 <meta charset> 和 <title> 之后、首个外部资源标签之前，否则无效。
怎么写 href 才让 dns-prefetch 真生效
浏览器只从 href 中提取主机名做 DNS 查询，其余内容全被忽略，写错就等于没加，而且控制台零报错——这是最常踩的坑。
-
//cdn.example.com是最稳妥写法：协议相对，适配当前页 HTTP/HTTPS，旧版 Safari 也认 -
https://fonts.googleapis.com在 HTTPS 页面中更稳，但若页面是 HTTP，https://会失败 - 绝对不能带路径：
//cdn.example.com/js/app.js→ 整个<link>被静默丢弃 - 不能缺协议标识：
cdn.example.com→ 被当成本地路径，查的是your-site.com/cdn.example.com - 不支持端口、查询参数、通配符：
//api.example.com:8080、//*.example.com全无效
放在 HTML 的哪个位置才来得及执行
浏览器流式解析 HTML，<link rel="dns-prefetch"> 一读到就立即排队发起 DNS 查询。放晚了，首屏资源请求早就发出去了，预解析纯属空转。
- ✅ 必须在
<meta charset>和<title>之后、首个<link rel="stylesheet">或<script src>之前 - ❌ 塞进
<body>里：规范不保证执行，多数浏览器会延迟甚至跳过 - ❌ 包在
<template>中或用 JS 动态插入（如document.createElement('link')）：完全不触发 DNS 查询 - ⚠️ Safari 更保守：可能等到空闲或用户交互后才执行，所以越早放，越有机会抢在首屏后请求前完成
哪些域名值得加，哪些加了反而拖慢页面
dns-prefetch 是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询不仅白耗资源，还会挤占关键请求的调度队列。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- ✅ 值得加：
//api.example.com（首屏后立即fetch()）、//fonts.googleapis.com（CSS @import 明确引用）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 别加：
//your-site.com（同源，DNS 已缓存）、//admin.example.com（子域共享主域 DNS 缓存）、//ad.doubleclick.net（不稳定、常被拦截） - ⚠️ 不要为 cdn1/cdn2 分别加多个：它们往往共用同一主域 DNS 缓存，重复加无收益
- ⚠️ 它只加速后续异步请求（懒加载图片、JS 中 fetch、字体 CSS 加载），对首屏内联资源或同步
<script>无作用
和 preconnect 混用会怎样
同一域名上同时写 <link rel="dns-prefetch"> 和 <link rel="preconnect"> 是冗余且有害的：后者已隐含 DNS 解析，前者会被浏览器直接忽略，还可能干扰 DNS 查询队列调度。
立即学习“前端免费学习笔记（深入）”；
- ✅ 关键资源（如首屏必加载的 CDN、API）优先用
<link rel="preconnect" href="https://cdn.example.com" crossorigin> - ✅ 不确定是否真用、或仅少量资源（如点击后才加载的第三方组件）用
dns-prefetch - ❌ 同一域名混用两者：浪费标签、增加 HTML 体积、干扰调度
- ⚠️
preconnect开销更大（DNS + TCP + TLS），HTTP/1.1 下连接池有限，总数建议 ≤6；dns-prefetch轻量，但并发数也受限制，别堆满
