DNS解析是页面加载的前置关键步骤，浏览器依次查询浏览器缓存、hosts文件、系统DNS缓存，未命中才向本地DNS服务器发起迭代查询，最终通过根→TLD→权威服务器链路获取IP。

DNS 解析不是前端代码执行环节，但它是页面加载链路上不可跳过的前置步骤——浏览器拿到 URL 后，fetch、img、script 标签都得等 DNS 返回 IP 才能发请求。面试问这个，本质是考你对「网络请求真实起点」的理解，不是背流程。

浏览器发起请求前先查哪几层缓存

用户敲下回车后，解析不从网络开始，而是一路向下查本地缓存：

• 浏览器进程级 DNS 缓存：Chromium 系内核（Chrome、Edge）自带缓存，寿命默认 1 分钟（dns_prefetch 可提前触发）
• 操作系统 hosts 文件：路径是 /etc/hosts（Linux/macOS）或 C:\Windows\System32\drivers\etc\hosts（Windows），优先级高于网络查询
• 系统 DNS 缓存服务：macOS 的 mDNSResponder、Windows 的 DNS Client 服务、Linux 的 systemd-resolved，TTL 遵守记录中设置的值
• 若全部未命中，才把查询交给配置的 本地 DNS 服务器（如 8.8.8.8 或运营商 DNS）

本地 DNS 怎么一步步找到权威服务器

本地 DNS 收到请求后，自己不递归到底，而是走标准迭代路径：

• 向根域名服务器（.）查 .com 的地址 → 根服务器返回一组 .com 顶级域（TLD）服务器 IP
• 向其中一台 .com TLD 服务器查 baidu.com 的权威服务器 → 返回 ns1.baidu.com 等地址
• 向 ns1.baidu.com 查 www.baidu.com 的 A 记录 → 终于拿到 IP
• 整个过程用的是 UDP 53 端口；若响应 > 512 字节或超时，会降级走 TCP 53

注意：根服务器全球只有 13 组 IP，但通过任播（Anycast）部署在上千个物理节点，不是单点。

Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转

实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。

下载

为什么 DNS 查询有时快有时慢

延迟差异主要来自三处：

• TTL 过期：比如某记录 TTL=300（5 分钟），过期后必须重走完整迭代链，耗时常达 200–500ms
• 本地 DNS 质量差：某些 ISP DNS 响应慢、缓存策略激进、甚至劫持（返回广告页 IP）
• 域名层级深：像 a.b.c.example.co.uk 比 example.com 多查一级 TLD，多一次 RTT
• 浏览器强制禁用缓存时（DevTools 的 Disable cache），每次都会绕过所有本地缓存直连本地 DNS

前端能干预 DNS 解析的手段有限但关键

纯 HTML/JS 层面无法改写解析逻辑，但可主动触发或优化时机：

• 用 提前解析关键域名（注意只支持 HTTPS 域名）
• 避免在 script 中动态拼接域名请求（如 fetch(domain + '/api')），否则无法被 dns-prefetch 覆盖
• HTTP/2 或 HTTP/3 下，复用连接可减少后续请求的 DNS 查询次数（前提是同 host）
• 不要依赖 document.domain 或 iframe 的跨域 DNS 行为做逻辑判断——它不改变解析过程，只影响同源策略

真正卡住页面首屏的，往往不是 DNS 本身，而是「第一个 DNS 查询没预热」+「TTL 设置过长导致更新延迟」+「本地 DNS 不可靠」这三者叠加。排查时优先 dig www.example.com @8.8.8.8 对比 nslookup，再看浏览器 Network 面板里 DNS 时间戳。

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