dns-prefetch仅对后续异步请求生效，需正确格式（如//cdn.example.com）、置于meta/title后首个外部资源前，且不超并发上限；同源或已解析域名无需添加，滥用反拖慢性能。

dns-prefetch 不加速首屏资源加载

它只对 JS 中 fetch()、懒加载图片、字体 CSS 引入、点击后动态加载的第三方组件等「后续异步请求」生效。首屏直接写在 HTML 里的 <script src="https://cdn.example.com/app.js"></script> 或 <link rel="stylesheet" href="https://cdn.example.com/main.css">，浏览器解析到就立刻发请求，dns-prefetch 再早也赶不上——除非你把预解析标签放在这些标签之前，且目标域名尚未被解析过。

href 格式错一点就完全失效，且零报错

浏览器只提取 href 中的主机名，其余内容全丢弃，写错等于没写，控制台不提示、Network 面板无记录，极难排查。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• //cdn.example.com ✅ 正确（协议相对 URL，推荐）
• https://fonts.googleapis.com ✅ 可接受（HTTPS 页面更稳）
• https://cdn.example.com/js/app.js ❌ 含路径，整个标签被静默忽略
• cdn.example.com ❌ 缺 //，被当成本地路径处理
• http://api.example.com ❌ HTTPS 页面中 Safari 等常跳过

位置放错等于白加，且 Safari 行为更保守

必须紧接在 <meta charset> 和 <title></title> 之后、首个外部资源（如 <link rel="stylesheet"> 或 <script src></script>）之前。塞进 、插在 JS 后、或用 JS 动态插入，DNS 查询根本不会触发。

• Safari 14+ 虽支持，但常延迟到页面空闲或用户 hover 后才执行，不像 Chrome 那样在 HTML 解析阶段就排队
• 即使位置正确，若前面堆了大量 CSS/JS，DNS 查询可能被首屏关键资源抢占调度优先级
• uBlock Origin 等广告拦截扩展会主动屏蔽 dns-prefetch 请求，实测时需禁用扩展验证

并发上限硬限制，乱加反而拖慢真实请求

每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发队列通常仅开放 6～10 个槽位。无效或冗余的预解析不仅浪费系统资源，还可能挤占后续真实请求的查询机会。

• 同源域名（如 //your-site.com）没必要加，浏览器已缓存或自动优化
• 子域共享主域 DNS 缓存（如 //admin.example.com 和 //cdn.example.com），加一个就够了
• 广告、社交分享等“可能用但不紧急”的域名，更适合用 rel="prefetch"，而非 dns-prefetch
• 同一域名不能同时写 dns-prefetch 和 preconnect，后者会覆盖前者，纯属冗余

真正起作用的点很窄：确定要用、跨域、异步、且还没被解析过的第三方域名，加上正确格式 + 正确位置 + 不超并发数。其他情况，不是没效果，就是反效果。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！