从输入 URL 到页面展示，经历了哪些过程？

核心回答

可以沿着解析地址、取得资源、处理文档、渲染画面这条主线回答。以访问一个 HTTPS 页面为例：

1. 解析 URL 与检查本地条件：识别协议、主机、端口、路径等信息，判断是否能使用缓存或已有连接。
2. 解析域名：需要建立新连接且没有可用地址信息时，通过本地解析机制和 DNS 获取目标地址；缓存命中时可以减少查询。
3. 建立连接与安全通道：HTTP/1.1、HTTP/2 常使用 TCP，HTTPS 再进行 TLS 协商；HTTP/3 使用集成 TLS 的 QUIC，不走同一套 TCP 建连流程。
4. 发送请求、接收响应：请求可能经 CDN、网关或反向代理到达服务，服务返回状态、响应头和内容；遇到重定向，则按新地址继续处理。
5. 解析 HTML 并加载子资源：构建 DOM，获取和解析 CSS、JavaScript、图片等；资源加载、文档解析和部分执行过程会交错推进。
6. 生成画面并持续更新：计算样式，布局确定大小与位置，绘制并合成显示。脚本执行和后续资源到达还可能继续修改页面。

这不是每次访问都完整执行的串行清单：缓存、连接复用和页面内导航可能跳过部分网络工作；浏览器也不必等所有资源下载完成才显示首屏。

地址怎样变成一次网络请求

例如访问 https://example.com/products?id=12#reviews：协议是 HTTPS，主机是 example.com，未显式指定时使用默认端口，路径和查询参数用于请求对应资源。#reviews 是片段标识，通常由浏览器用于页面内定位，不作为 HTTP 请求目标发送给服务器。

需要网络请求时，浏览器先考虑已有连接、地址缓存等信息。DNS 解析也不是浏览器每次亲自从根服务器一路查到底：客户端通常向递归解析器请求结果，解析器根据缓存情况，再向相关权威层级查询。一个域名可能对应多个地址，CDN 也可能把请求引导到不同服务节点。

本地缓存、操作系统解析器、hosts 与安全 DNS 的使用方式受浏览器和系统配置影响，面试时不宜把它们背成所有环境下固定不变的检查顺序。

连接、请求与服务器处理怎样衔接

新建基于 TCP 的 HTTPS 连接时，要完成传输连接与 TLS 协商，包括验证服务器身份、协商后续通信所用的密钥。连接可以复用，握手细节也受协议版本、会话恢复等影响，因此不能给所有 HTTPS 请求规定固定的握手次数或往返数。

连接可用后，浏览器发送方法、请求目标、请求头及必要的请求体。CDN 或代理可能直接返回缓存内容，也可能把请求交给后端；后端再进行路由、鉴权、数据库访问或其他业务处理。浏览器关心的是最终收到的响应，而不要求每次请求都到达源站应用。

响应头决定后续如何处理内容：重定向可能触发新地址请求；需要重新验证的缓存可能在收到 304 后复用已有响应体；HTML 进入文档处理流程，其他类型也可能成为图片、数据或下载文件。网络请求成功，不代表页面已经绘制完成。

浏览器如何把 HTML 变成像素

HTML 数据可以边到达边解析，逐步建立 DOM。发现样式、脚本、图片和字体后，浏览器继续安排资源获取；预加载扫描等机制也能提前发现资源，减少等待。

CSS 解析后参与样式计算，浏览器据此确定哪些内容需要显示、采用什么样式。随后布局计算几何位置与大小，绘制生成需要呈现的内容，再通过相应的栅格化与合成过程形成屏幕画面。这里是常用的渲染过程概括，具体内部数据结构和线程分工由浏览器实现决定。

这些阶段存在依赖，但不是“先下载全部文件，再统一渲染”：普通同步脚本可能暂停 HTML 解析，样式会影响首屏呈现，图片尺寸或脚本修改又可能触发布局与绘制。页面已经可见时，主线程仍可能忙于 JavaScript，导致交互响应迟缓；“看到内容”“资源加载结束”“交互流畅”是不同的观察点。

常见追问

命中缓存，是不是完全不发请求了？

要看是哪种缓存、缓存什么。有效的本地 HTTP 缓存可以避免该资源的网络获取；重新验证仍要发请求。HTML 被缓存，也不代表它引用的所有图片、脚本和接口数据都已缓存。DNS 缓存和连接复用则分别减少解析、建连工作，不等于取得了页面内容。

页面显示后，TCP 就会四次挥手吗？

不一定。HTTP 连接可以保留复用，HTTP/2 还可以在同一连接上承载多个流；HTTP/3 使用 QUIC。页面绘制结束不是所有连接立即关闭的条件，后续还可能继续请求数据。

页面白屏，应该从哪个阶段查？

先看主文档是否成功返回、是否发生错误重定向，再检查 CSS、JS 和接口请求。主文档正常而页面仍空白时，继续看脚本报错、初始化流程和样式是否隐藏内容；能显示但卡顿，则检查主线程长任务、布局和绘制。沿链路缩小范围，比把所有问题都归为“网络慢”更有效。

参考资料