导航流程：从输入URL到页面展示这中间发生了什么|浏览器篇

“在浏览器里，从输入URL到页面展示，这中间发生了什么？ ”这是一道经典的面试题，能比较全面地考察应聘者知识的掌握程度，其中涉及到了网络、操作系统、Web等一系列的知识。所以我在面试应聘者时也必问这道题，但遗憾的是大多数人只能回答其中部分零散的知识点，并不能将这些知识点串联成线，无法系统而又全面地回答这个问题。

那么今天我们就一起来探索下这个流程，下图是我梳理出的“从输入URL到页面展示完整流程示意图”：

从图中可以看出，整个过程需要各个进程之间的配合，所以在开始正式流程之前，我们还是先来快速回顾下浏览器进程、渲染进程和网络进程的主要职责。

• 浏览器进程主要负责用户交互、子进程管理和文件储存等功能。
• 网络进程是面向渲染进程和浏览器进程等提供网络下载功能。
• 渲染进程的主要职责是把从网络下载的HTML、JavaScript、CSS、图片等资源解析为可以显示和交互的页面。因为渲染进程所有的内容都是通过网络获取的，会存在一些恶意代码利用浏览器漏洞对系统进行攻击，所以运行在渲染进程里面的代码是不被信任的。这也是为什么Chrome会让渲染进程运行在安全沙箱里，就是为了保证系统的安全

回顾了浏览器的进程架构后，我们再结合上图来看下这个完整的流程，可以看出，整个流程包含了许多步骤，我把其中几个核心的节点用蓝色背景标记出来了。这个过程可以大致描述为如下：

• 首先，用户从浏览器进程里输入请求信息；
• 然后，网络进程发起URL请求；
• 服务器响应URL请求之后，浏览器进程就又要开始准备渲染进程了；
• 渲染进程准备好之后，需要先向渲染进程提交页面数据，我们称之为提交文档阶段；
• 渲染进程接收完文档信息之后，便开始解析页面和加载子资源，完成页面的渲染。

这其中，用户发出URL请求到页面开始解析的这个过程，就叫做导航。下面我们来详细分析下这些步骤，同时也就解答了开头所说的那道经典的面试题。

知道了浏览器的几个主要进程的职责之后，那么接下来，我们就从浏览器的地址栏开始讲起。

原理拆解： 用户在地址栏确认输入后，浏览器进程先判断内容是搜索词还是可导航的 URL，再通过 IPC 把网络任务交给网络进程。网络进程检查缓存、解析 DNS、建立连接并发送请求；访问 HTTPS 页面时，连接阶段还包含 TLS 协商。收到响应头后并不会立即开始解析页面：若状态码为 301 或 302 且存在 Location，浏览器会针对新地址重新发起导航；若 Content-Type 表明内容应作为下载处理，则交给下载流程；只有确认响应是可渲染的 HTML 文档后，才进入渲染进程准备与文档提交阶段。

具体例子： 输入 example.com 后，浏览器可能补全协议并请求站点。若服务器返回 302，将地址指向登录页，网络进程会继续请求登录页，而不是把首次响应当作页面渲染。登录页响应为 text/html 后，浏览器为导航选择或创建合适的渲染进程。提交文档时，响应体被交给渲染进程，渲染进程确认接收后，浏览器进程更新地址栏、历史记录和安全状态；随后渲染进程解析 HTML、构建 DOM，并触发样式表、脚本和图片等子资源请求。

边界与排查： 回车后旧页面通常不会立刻被清空，因为新导航可能遇到网络等待、重定向、证书错误或下载分流，只有新文档提交后才完成页面切换。同站点是否复用渲染进程受浏览器的站点隔离策略、现有进程状态和具体版本影响，不能简单等同于“同域名一定同进程”。页面看似白屏也不一定是网络失败，可能是文档已提交，但脚本执行、样式计算或渲染阶段发生阻塞。

工程验证： 在开发者工具的 Network 面板勾选保留日志后执行导航，按时间查看 Document 请求、重定向链、状态码和 Content-Type；通过 Timing 区分域名解析、连接、等待响应与下载耗时。若文档请求正常但页面未展示，再检查 Console 错误、子资源请求以及主线程长任务，从而判断故障发生在导航、文档提交还是页面生成阶段。