浏览器与网络

进程和线程

浏览器的渲染过程

重绘和回流

浏览器的缓存机制

浏览器缓存是浏览器为了提升资源加载速度、减少网络请求、降低服务器压力而对已加载资源进行本地存储的机制。其核心逻辑是 **"优先使用本地缓存，缓存失效时再请求服务器"**，并通过分层缓存策略和缓存规则（HTTP 头）实现精细化控制。

（一）浏览器缓存的核心分层

1.Memory Cache(内存缓存)

a.存储位置：浏览器内存

b.特点：读写速度快（内存 IO 远快于磁盘 IO）；

生命周期最短：关闭浏览器标签页后，内存缓存立即清除

c.存储内容：通常是刚刚加载过的短期高频使用资源（如 JS、CSS、图片的临时副本）

d.示例：刷新页面时，部分资源（如小图片、轻量 JS）会直接从内存缓存读取，无需重新请求。

2.Service Worker Cache(服务工作线程缓存)

a.存储位置：浏览器磁盘（独立于其他缓存的自定义缓存）

b.特点：由开发者通过Service Worker API手动控制（需注册 Service Worker）

支持 "离线缓存"：即使网络断开，也能通过 Service Worker 读取缓存资源（PWA 核心能力）

c.存储内容：开发者自定义的资源（如 HTML、JS、CSS、接口数据）。

d.示例：离线访问 PWA 应用时，页面和静态资源从 Service Worker Cache 加载。

3.Disk Cache(磁盘缓存)

a.存储位置：浏览器本地磁盘

b.特点：读写速度慢于内存缓存，但快于网络请求；

生命周期长：关闭浏览器后仍保留（直到过期或被手动清理）

c.存储内容：长期使用的资源（如大型图片、JS 库、CSS 框架）

d.示例：关闭浏览器后重新打开，之前加载过的 JS 库（如 jQuery）会从磁盘缓存读取，无需重新下载。

4.Push Cache(推送缓存)

a.存储位置：浏览器临时推送缓存（HTTP/2 特性）

b.特点：优先级最低，仅在上述 3 层缓存都未命中时生效；

生命周期极短：仅持续到当前会话（关闭浏览器即清除）；

依赖 HTTP/2 Server Push 机制：服务器主动将资源 "推" 给浏览器并缓存，无需浏览器请求。

c.适用场景：HTTP/2 环境下，服务器预判浏览器需要的资源（如页面依赖的 CSS），提前推送并缓存。

(二) 缓存的"有效性控制"：HTTP 缓存规则

浏览器如何判断 "缓存是否有效"？核心依赖 HTTP 响应头 中的缓存字段，分为两大策略：强缓存 和 协商缓存。

1.强缓存（直接使用本地缓存，不发请求）

浏览器通过响应头判断资源是否 "未过期"，若未过期则直接使用本地缓存，不向服务器发送任何请求。

控制强缓存的 HTTP 头有 2 个（优先级: Cache-Control> Expires）

响应头	作用	示例
Cache-Control	HTTP/1.1 标准字段，通过 "指令" 控制缓存（优先级高于 Expires）	Cache-Control`: max-age=3600`
Expires	HTTP/1.0 字段，通过 "绝对时间" 指定缓存过期时间（易受本地时间影响）	Expires`: Wed, 29 Oct 2025 12:00:00 GMT`

Cache-Control的核心指令：

max-age=xxx：缓存有效期（单位：秒），从资源首次请求成功时开始计时（如 max-age=3600 表示 1 小时内有效）；
no-store：完全不缓存资源（每次都需从服务器重新请求）；
no-cache：不使用强缓存，必须触发协商缓存（每次请求需和服务器确认缓存是否有效）；
public：允许所有角色缓存（如浏览器、CDN、代理服务器）；
private：仅允许浏览器缓存（禁止 CDN、代理服务器缓存，常用于用户个性化资源）。

2.协商缓存（发请求确认缓存，未过期则复用）

强缓存过期后，浏览器会向服务器发送协商请求（带缓存标识），由服务器判断缓存是否仍有效：

若有效：服务器返回 304 Not Modified，浏览器复用本地缓存；
若无效：服务器返回 200 OK 和新资源，浏览器更新本地缓存。

协商缓存的核心是 "缓存标识"，分为 2 组 （优先级：ETag/If-None-Match > Last-Modified/If-Modified-Since）：

类型	响应头（服务器返回，标记资源特征）	请求头（浏览器携带，验证缓存）	核心逻辑
ETag 组	`ETag: "abc123"`	`If-None-Match: "abc123"`	服务器对资源生成唯一 "指纹"（如哈希值），浏览器请求时携带指纹；服务器对比指纹，一致则缓存有效。
Last-Modified 组	`Last-Modified: Wed, 28 Oct 2025 10:00:00 GMT`	`If-Modified-Since: Wed, 28 Oct 2025 10:00:00 GMT`	服务器返回资源最后修改时间；浏览器请求时携带该时间，服务器判断资源是否在该时间后修改，未修改则缓存有效。

两组标识的差异：

维度	Last-Modified/If-Modified-Since	ETag/If-None-Match
精度	秒级（无法识别 1 秒内的多次修改）	毫秒级 / 哈希级（精度更高）
适用场景	静态资源（如图片、JS，修改频率低）	动态资源（如接口数据、频繁修改的文件）
性能	服务器判断成本低（仅对比时间）	服务器判断成本高（需计算资源哈希）

(三）浏览器缓存的完整流程（优先级逻辑）

当浏览器请求一个资源时，会按以下顺序判断缓存：

检查 Memory Cache：若资源在内存中且未失效，直接使用；
检查 Service Worker Cache：若注册了 Service Worker，且资源在其缓存中，直接使用（可自定义逻辑）；
检查 Disk Cache ：
- 先判断强缓存（Cache-Control/Expires）：若未过期，直接使用 Disk Cache；
- 若强缓存过期，触发协商缓存 ：向服务器发送请求，携带 If-None-Match/If-Modified-Since；
服务器判断协商缓存 ：
- 若缓存有效（资源未修改），返回 304 Not Modified，浏览器复用 Disk Cache；
- 若缓存无效（资源已修改），返回 200 OK 和新资源，浏览器更新 Disk Cache 和 Memory Cache；
Push Cache：仅在上述 4 步均未命中，且支持 HTTP/2 Server Push 时，使用 Push Cache。

(四）缓存策略的实际应用场景

资源类型	推荐缓存策略	示例配置
静态资源（JS/CSS/ 图片）	强缓存 + 协商缓存（长期 `max-age` + 指纹（如 `app.[hash].js`））	`Cache-Control: max-age=31536000`
入口 HTML	禁用强缓存，仅用协商缓存（避免 HTML 过期导致静态资源无法更新）	`Cache-Control: no-cache`
接口数据（API）	协商缓存（短期 `max-age` 或 `no-cache`，避免数据实时性问题）	`Cache-Control: max-age=60`
临时资源（如验证码）	完全不缓存	`Cache-Control: no-store`

(五）缓存的 "更新与清理"

主动更新 ：通过 "资源指纹"（如 app.v2.js 替换 app.v1.js），由于文件名变化，浏览器会认为是新资源，重新请求并更新缓存；
被动清理：
- 缓存过期：强缓存 max-age 到期或协商缓存被服务器拒绝；
- 容量满了：浏览器按 LRU 策略清理磁盘缓存中 "最近最少使用" 的资源；
- 手动清理：用户通过浏览器设置（如 Chrome "清除浏览数据"）删除缓存。

总结

浏览器缓存是 "性能优化的基石"，核心逻辑是 **"分层存储 + HTTP 规则控制"**：

按优先级从高到低：Memory Cache → Service Worker Cache → Disk Cache → Push Cache；
按有效性控制：强缓存（快速复用，不发请求）→ 协商缓存（确认后复用，发请求但不传资源）；
实际应用中，需结合资源类型（静态 / 动态、实时性）选择合适的缓存策略，平衡 "速度" 与 "新鲜度"。

浏览器存储（cookie，webstorage）

浏览器安全（xss和csrf）

浏览器的跨域问题及解决方法

浏览器的跨域问题本质是浏览器基于 "同源策略"（Same-Origin Policy）的安全限制 ------ 当一个网页的脚本（如 JS）试图请求另一个域名、端口或协议的资源时，浏览器会拦截该请求，防止恶意网站窃取敏感数据（如 Cookie、LocalStorage）。

跨域是：跨域的请求会正常发送到服务器，服务器也会处理并返回响应。但是当浏览器检测到响应的"源"与当前页面不同，且服务器未明确允许跨域时，会丢弃响应，并在控制台报"CORS错误"。（如 Access to XMLHttpRequest at 'xxx' from origin 'xxx' has been blocked by CORS policy）即就是请求已发出，但浏览器会拦截响应

1.同源

"同源" 要求两个资源的 协议、域名、端口 完全一致。只要有一个不一致，就属于 "跨域"。

2.跨域常见场景

a.Ajax/Fetch请求：最常见，如js调用其他域名的接口（如前端localhost:8080调用后端localhost:3000的接口）

b.DOM操作：如通过iframe嵌入其他域名的页面，尝试获取iframe内的 DOM 元素（会被拦截）。

c.资源加载：虽然<script><link><img><video>等标签的 "资源加载" 不会被跨域拦截（否则 CDN 无法使用），但脚本执行时的跨域访问仍会受限（如 JSONP 利用了<script>加载无跨域限制的特性）。

3.解决方案

①后端配置CORS

CORS（Cross-Origin Resource Sharing，跨域资源共享）是 W3C 标准，通过后端在响应头中添加Access-Control-*字段，明确告知浏览器 "允许该域名跨域访问"，浏览器会放行响应。

②前端配置代理（开发环境常用，如 Vue CLI、Vite）

开发阶段，前端项目（如 Vue 项目运行在 localhost:8080）调用后端接口（如 localhost:3000）会跨域。此时可通过前端构建工具的代理功能，将前端请求 "转发" 到后端，避免跨域（本质是 "同源请求代理服务器，代理服务器再跨域请求后端"，而浏览器只与代理服务器同源）。

③JSONP（兼容性好，但仅限 GET 请求）

早期的跨域方案，利用<script>标签"加载资源无跨域限制"的特性实现：

a.前端动态创建<script>标签，src指向后端接口（携带回调函数名，如?callback=handleData)

b.后端接收请求后，返回"回调函数调用+数据"的js代码（如handleData({message:'JSONP成功'}) ）

c.前端执行js代码，通过回调函数获取数据。

get请求和post请求的区别

常见的状态码

状态码 第一位数字 决定了 不同的响应状态，有如下：

1 表示信息
2 表示成功
3 表示重定向
4 表示客户端错误
5 表示服务器错误

1xx（信息性状态码）

表示请求已被接受，需要继续处理 。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束

常见的有：

100**（客户端继续发送请求，这是临时响应）**：这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应
101：服务器根据客户端的请求切换协议，主要用于websocket或http2升级

2xx（成功状态码）

表示 请求已成功被服务器接受

200（成功） 表示请求已成功，请求期望的响应头或数据体会随此响应返回，是最常见的成功状态标识。
201（已创建）意味着请求成功，且服务器创建了新的资源，比如创建新文件、新用户等场景下可能出现。
202（已接受）服务器已接收请求，但尚未处理完成，它告知客户端请求已收到，后续会进行处理，不过不代表处理结果。
203（非授权信息）服务器成功处理了请求，不过返回的信息可能来自其他非权威来源，暗示响应内容存在一些特殊情况。
204（无内容） 服务器成功处理了请求，不过没有返回任何内容，常用于只需确认操作执行成功，无需返回数据的场景，像删除操作后可返回此状态码。
205（重置内容）同样是服务器成功处理请求且无返回内容，它还带有让客户端重置文档视图（比如清空表单数据等）的暗示。
206（部分内容） 用于表示服务器成功处理了部分请求，典型应用在断点续传或分块下载场景，客户端可据此继续获取剩余部分数据

3xx（重定向状态码）

表示要完成请求，需要进一步操作。通常，这些状态码用来重定向

常见的有：

301：表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
302：表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问
304（协商缓存）：服务器通过返回状态码304可以告诉客户端请求资源成功，但是这个资源不是由服务器提供返回给客户端的，而是客户端本地浏览器缓存中就有的这个资源，因为可以从缓存中获取这个资源**，从而节省传输的开销。 -

301 和 302 都会在响应头里使用字段 Location ，指明后续要跳转的 URL，浏览器会自动重定向到新的 URL

4xx（客户端错误状态码）

表示服务器无法处理请求，客户端出现错误。

401（未授权）：请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
403（禁止）：服务器拒绝请求
404（未找到）：请求的资源不存在 -
405（方法禁用）：禁用请求中指定的方法 -
406（不接受）：无法使用请求的内容特性响应请求的网页 -'
407（需要代理授权）：此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理
408（请求超时）：服务器等候请求时发生超时

5xx（服务器错误状态码）

表示服务器无法完成明显有效的请求。这类状态码代表了服务器 在处理请求的过程中有错误或者异常状态发生

500（服务器内部错误）：服务器遇到错误，无法完成请求
501 （尚未实施）：服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此状态码
502（错误网关）：通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误
503（服务不可用）：表示服务器当前很忙，暂时无法响应客户端，类似 "网络服务正忙，请稍后重试" 的意思。
504（网关超时）：服务器作为网关或代理，但是没有及时从上游服务器收到请求
505（HTTP 版本不受支持）：服务器不支持请求中所用的 HTTP 协议版本

常见的请求头和响应头

http1.1和1.0的区别

http/2和 http1.1 的区别

HTTP/2协议是基于HTTPS的，所以HTTP/2的安全性是有保障的

1.头部压缩：

HTTP/2 使用HPACK 算法压缩头（Header）。如果同时发出多个请求，它们的头是一样的或是相似的，那么，协议会帮我们消除重复的部分

HPACK 算法：在客户端和服务器之间维护一张共享的头信息表，存储常用的 HTTP 头字段及其索引号。在传输头信息时，如果某个字段已经存在于这张表中，客户端或服务器只需发送该字段的索引号，而不是完整的头信息
**在***HTTP/1.1中，头部信息通常是未压缩的，这会导致大量的冗余数据传输。**

2.二进制格式：

HTTP/2.0使用二进制格式。二进制格式就是0 1字符串，因为计算机底层就是 0 1字符串，所以二进制格式组成的数据更易于解析
HTTP/1.1使用的是文本的格式

3.多路复用：

HTTP/1.1 的"管道化"

原理：允许客户端在同一个 TCP 连接上连续发送多个请求（无需等待上一个请求的响应返回）。
问题：
- 服务端的响应必须按客户端发送请求的顺序返回* *（先进先出）。如果第一个请求的响应延迟，后续已发送的请求的响应会被阻塞（队头阻塞）。
  - 验证：
    - 这是 HTTP/1.1 管道化的最大缺陷。例如：若 GET /a 的响应卡住，即使 GET /b 的响应已准备好，也无法提前返回。
- 浏览器默认禁用：实现复杂且容易出错（如代理服务器可能不支持）。

HTTP/2 的多路复用

帧：帧代表着最小的数据单位,每个帧会标识出该帧属于哪个流

流也就是多个帧组成的数据流
- 原理：
  - 将请求和响应分解为二进制帧（Frames） ，每个帧携带唯一的流ID（Stream Identifier）。
  - 多个请求/响应的帧可以在同一 TCP 连接上交错传输，服务器和客户端通过流ID重组数据。
- 优势：
  - 真正的并行传输：响应无需按顺序返回，解决了队头阻塞。

4.服务器推送：

HTTP/2.0允许服务器主动向客户端推送资源**，而不是等待客户端明确请求。这可以**减少额外的往返时间，提高页面加载速度**。
HTTP/1.1他只能是客户端向服务器请求数据，服务器不能向客户端推送资源

5.优先级和流控制：

HTTP/2.0：

允许客户端设置流的优先级 ，使服务器能够根据优先级处理请求，从而优化资源利用和响应时间。

HTTP/1.1：

不支持流的优先级管理 ，所有请求被视为平等处理，无法根据重要性或紧急性进行优化。

http3和http2的区别

https 相比http如何保证安全

HTTP 直接通过 TCP 传输明文数据，所有信息（如账号密码、支付信息）在网络中 "裸奔"；而 HTTPS 在 HTTP 与 TCP 之间插入了 TLS（Transport Layer Security/Secure Sockets Layer，TLS 是 SSL 的升级版，目前主流为 TLS 1.2/1.3），所有 HTTP 数据需先经过 TLS 加密，再通过 TCP 传输。

HTTP 流程：应用层（HTTP）→ 传输层（TCP）→ 网络层 → 物理层（明文）
HTTPS 流程：应用层（HTTP）→ 加密层（TLS/SSL）→ 传输层（TCP）→ 网络层 → 物理层（加密后的数据）

安全维度	HTTP（明文）	HTTPS（TLS+HTTP）
数据传输	明文，可被窃听（如抓包工具直接查看）	对称加密，仅客户端 / 服务器可解密
服务器身份	无验证，易被伪造（中间人攻击）	SSL 证书验证，确保连接真实服务器
数据完整性	无校验，数据可被篡改且无法察觉	MAC 校验，篡改后可立即识别并中断连接
浏览器信任	无特殊标识，部分场景（如支付）被禁止	地址栏显示 "小锁" 图标，标注 "安全"，提升信任

tcp 的三次握手和四次挥手

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接、可靠的传输层协议，在数据传输前需要通过三次握手建立连接 ，传输结束后通过四次挥手断开连接。这两个过程是保证 TCP 可靠性的核心机制。

（一）三次握手（建立连接）

TCP 是 "面向连接" 的协议，通信双方在传输数据前必须先建立逻辑连接，这个过程通过 "三次握手" 完成，目的是确保双方的发送和接收能力都正常。比如客户端（如浏览器）要向服务器请求数据（如访问网页），需先通过三次握手与服务器建立 TCP 连接。

1.第一次握手（客户端->服务器）

客户端发送一个SYN（同步序列编号）报文，随机生成一个初始序列号seq=x（用于后续数据传输的编号，保证数据有序）

含义："服务器你好，我想和你建立连接，我的初始序号是 x，你能收到吗？"

2.第二次握手（服务器->客户端）

服务器收到SYN报文后，确认自己的接收能力正常，回复一个SYN+ACK(Acknowledgement确认)报文，SYN:服务器也生成一个初始序列号seq = y ACK:确认收到客户端的 SYN，确认号 ack = x + 1（表示 "已收到 x 及之前的所有数据，下次请从 x+1 开始发"）。

含义："客户端你好，我收到你的请求了，我的初始序号是 y，你可以开始发数据了，我准备好了。"

3.第三次握手（客户端->服务器）

客户端收到 SYN + ACK 报文后，确认自己的发送和接收能力、服务器的发送和接收能力都正常，回复一个 ACK报文：确认号ack = y +1（标识已经收到y及之前的所有数据，下次请从y+1开始发）客户端序列号seq = x +1

含义："服务器我知道了，你的信息我已收到，现在我们可以正式传输数据了。"

（二）四次挥手（断开连接）

TCP 连接是双向的，断开连接时需要双方都确认 "不再发送数据"，因此需要四次交互（四次挥手）。比如数据传输完成后（如网页加载完毕），客户端或服务器需要断开连接，释放资源。

1.第一次挥手（主动方->被动方）

主动关闭方（可能是客户端，也可能是服务端）发送一个FIN报文，序列号seq = u(d当前已发送数据的最后一个序号+1)

含义："我已经没有数据要发给你了，准备关闭我的发送通道，但我还能接收你的数据。"

2.第二次挥手（被动方->主动方）

被动方收到FIN后，回复一个ACK报文，确认号ack = u+1,序列号seq = v

含义："我知道你要关闭了，我会处理剩余数据，你等我通知。"
此时，主动方的发送通道关闭，但被动方仍可向主动方发送数据（半关闭状态）。

3.第三次挥手（被动方->主动方）

被动方处理完所有数据后，也准备关闭连接，发送一个FIN+ACK报文，序列号seq=w,确认号 ack=u+1（与第二次挥手的确认号一致，因主动方已无新数据）

含义："我也没有数据要发给你了，我的发送通道也准备关闭了。"

4.第四次挥手（主动方->被动方）

主动方收到FIN+ACK后，回复一个ACK报文，确认号ack=w+1,序列号ack = u+1。

含义："我知道你也要关闭了，现在可以彻底断开了。"
主动方发送 ACK 后，会等待一段时间（2MSL，约 2-4 分钟），确保被动方收到 ACK 后再关闭，避免被动方因未收到 ACK 而重发 FIN。

tcp和udp的区别

输入 url 会发生什么

当用户在浏览器地址栏输入一个 URL（如 https://www.example.com）并按下回车后，会触发一系列复杂的流程，从解析 URL 到最终页面呈现，涉及网络、操作系统、浏览器等多个层面。

（一）URL解析与预处理

1.验证URL合法性

浏览器首先判断输入的是URL-->直接解析　　还是关键词（eg天气）--->拼接默认的搜索引擎（egGoogle/百度）的搜索URL。

２.拆解URL结构

拆解为：协议（决定传输协议和端口，http默认80 https默认443）

域名（需要解析为ip地址）端口路径（服务器资源路径）查询参数（键值对参数）锚点（页面内定位，不发送到服务器）

（二）DNS域名解析（将域名转为IP地址）

浏览器无法直接通过域名访问服务器，需先通过 DNS（域名系统） 解析出对应的IP 地址（如 www.example.com → 192.168.1.1）解析流程遵循 "缓存优先" 原则：

浏览器缓存：检查浏览器本地缓存（如 Chrome 缓存 DNS 记录约 1 分钟到几小时），若有直接使用。
操作系统缓存 ：若浏览器缓存未命中，查询操作系统缓存（如 Windows 的 hosts 文件、系统 DNS 缓存）。
路由器缓存：查询路由器本地缓存（通常存储常用域名的 IP）。
ISP DNS 服务器：若前几步未命中，请求用户网络服务商（如电信、联通）的 DNS 服务器（本地 DNS），其缓存了大量域名的 IP 映射。
根域名服务器递归查询：若本地 DNS 也未命中，则开始递归查询：

本地 DNS → 根域名服务器（如 .）→ 顶级域名服务器（如 .com）→ 权威域名服务器（example.com 的专属 DNS），最终获取 IP 地址并返回给浏览器，同时各级缓存该结果。

（三）建立TCP连接（三次握手）

获取服务器 IP 地址后，浏览器通过 TCP 协议与服务器建立连接（HTTPS 在此基础上多一步 TLS 握手）

（四）发送HTTP/HTTPS请求

连接建立后，浏览器向服务器发送 HTTP 请求（以 GET 请求为例），请求内容包括请求行请求头请求体

（五）服务器处理请求并返回响应

1.解析请求：提取路径、参数、请求头，确定客户端需要的资源

2.处理业务逻辑

若为静态资源（HTML/CSS/JS），直接从服务器磁盘读取；
若为动态内容（如 PHP/JSP/Node.js 接口），调用后端程序处理（如查询数据库、计算结果）。

3.生成响应：服务器返回HTTP响应，包含状态行响应头响应体

（六）浏览器接收响应并渲染页面

1.解析HTML（构建DOM树）

2.解析CSS（构建CSSOM树）

3.构建渲染树（Render Tree）

4.布局（Layout/Reflow）

计算渲染树中每个节点的位置和大小（如宽高、坐标），确定元素在页面中的布局（此过程可能触发多次重排，影响性能）。

5.绘制（Paint）

根据布局结果，将元素的样式（颜色、背景、阴影等）绘制到屏幕上（可能触发重绘）。

6.合成（Composite）

浏览器将页面分层（如文字层、图片层），分别绘制后合并为最终屏幕图像（优化渲染性能，尤其动画场景）。

（七）断开连接（四次挥手）

（八）额外优化步骤

1.缓存处理：根据响应头的 Cache-Control、ETag 等字段，将资源（JS/CSS/ 图片）缓存到浏览器（内存 / 磁盘），下次请求直接复用。

2.预加载与与连接：浏览器可能对页面中的 link rel="preload" 资源提前加载，或对域名提前进行 DNS 解析和 TCP 连接，优化后续加载速度。

3.执行js：HTML 解析遇到 <script> 标签时，会暂停解析并执行 JS（可能操作 DOM/CSSOM，影响渲染），现代浏览器通过异步加载（async/defer）优化此过程。

websocket和SSE

跨标签通信的方法