【前端面试】浏览器&网络篇

• 【前端面试】HTML篇
• 【前端面试】CSS篇
• 【前端面试】JS篇
• 【前端面试】Vue篇
• 【前端面试】Git篇
• 【前端面试】前端工程化篇
• 【前端面试】手写题篇
• 【前端面试】前端性能优化篇
• 【前端面试】浏览器&网络篇

浏览器缓存

为什么需要浏览器缓存？

浏览器缓存主要是为了提高网页性能、减少网络请求和降低服务器压力。

1. 提升性能与用户体验
   • 浏览器缓存资源可以避免重复下载，页面加载更快，用户感知速度更好。
2. 减少带宽消耗和服务器压力
   • 对于静态资源，如果不每次都请求服务器，既节省用户网络流量，也降低服务器负载。
3. 支持离线访问和部分功能
   • 通过缓存，用户在网络不稳定或断网时仍然可以访问部分内容（比如 PWA 应用、图片资源等）。

强缓存 vs 协商缓存

强缓存优先于协商缓存，两者结合可以最大限度提升页面加载性能和降低服务器压力。

1. 强缓存（强制缓存）
   • 触发条件：浏览器在有效期内（由 Expires 或 Cache-Control:max-age 指定）直接使用本地缓存，不向服务器发送请求。
   • 特点：无需请求服务器，性能最高。
   • 控制方式：
     • Expires（HTTP/1.0，绝对时间）
     • Cache-Control（HTTP/1.1，相对时间，优先级高于 Expires）

2. 协商缓存（验证缓存）
   • 触发条件：缓存过期后，浏览器会向服务器发送请求，通过 If-Modified-Since 或 If-None-Match 询问资源是否有更新。
   • 特点：如果资源未修改，服务器返回 304 Not Modified，浏览器仍使用本地缓存；如果修改了，返回 200 + 新资源。
   • 控制方式：
     • Last-Modified / If-Modified-Since
     • ETag / If-None-Match

Etag 和 Last-Modified 的优劣

特性	Last-Modified	Etag
精确度	低（秒级），无法感知秒内变化	高，基于内容 Hash，任何变动都能感知
性能开销	小，只需读取文件元数据	相对较大，需要计算文件内容的 Hash 值
适用场景	对精度要求不高的场景	对精度要求高，能容忍少量服务器计算开销的场景
优先级	低	高（如果请求头同时包含 If-Modified-Since 和 If-None-Match ，服务器会优先验证 Etag ）

hash 和 history 模式

1. hash 模式
   • 原理：通过 URL 的 #（锚点）后面的内容来模拟路径变化，监听 hashchange 事件实现前端路由跳转。
   • 特点：
     • 改变 # 不会导致浏览器向服务器发请求。
     • 刷新不会 404，因为 # 后的内容不会被发送到服务器。
     • 兼容性好，不需要额外配置服务器。
   • URL 示例：https://example.com/#/home
2. history 模式
   • 原理：利用 HTML5 的 History API（pushState、replaceState）操作浏览器的历史记录，实现无 # 的路径切换。
   • 特点：
     • URL 更美观：https://example.com/home
     • 可以通过前端控制浏览器历史。
     • 但刷新时浏览器会真正向服务器请求该路径，需要后端做 路由 fallback 处理，否则会 404。
3. 总结区别
   • hash 模式：前端实现简单、兼容性好，但 URL 不够美观。
   • history 模式：URL 更自然，利于 SEO，但需要服务器支持。

当使用 history 或 hash 模式直接刷新带路径的页面会发生什么？

1. 使用 history 模式刷新：

• 浏览器会把当前完整路径（如 /about）直接发送给服务器。
• 如果服务器没有配置对应的路由（比如 Nginx 没做 fallback 到 index.html），
  ➜ 就会返回 404。
• 所以 history 模式必须由后端配置统一路由转发，否则刷新或手动输入路径会报错。

2. 使用 hash 模式刷新：

• 浏览器在请求时只会发送 # 前面的部分给服务器。
  例如：访问 https://example.com/#/about，实际请求的仍然是 /。
• 所以服务器永远返回同一个入口页面（index.html），前端再根据 # 后的 hash 渲染对应内容。
• ➜ 刷新不会 404。

GET 和 POST 的区别

1. 针对数据操作类型不同：GET 主要查询数据，POST 主要增删改数据
2. 参数大小不同：GET 参数有长度限制，POST 没有
3. 安全性不同：GET 参数通过 URL 传递，会暴露不安全，POST 相对安全
4. 浏览器回退表现不同：GET 在浏览器回退时无害，POST 会再次提交请求
5. 浏览器对请求地址的处理不同：GET 请求地址会被浏览器主动缓存，POST 不会
6. 浏览器对响应处理不同：GET 请求参数会被完整保留在历史记录中，POST 参数不会被保留

HTTP 状态码

HTTP 状态码用于表示服务器对请求的处理结果。

常见分类：

• 1xx：信息性状态（如 101 协议切换）
• 2xx：成功（200 OK、204 No Content、206 Partial Content）
• 3xx：重定向（301 永久、302 临时、304 未修改）
• 4xx：客户端错误（400 参数错误、401 未认证、403 禁止访问、404 未找到）
• 5xx：服务器错误（500 内部错误、502 网关错误、504 超时）

304 的过程

1. 浏览器发送请求时带上缓存验证字段：
   • If-Modified-Since（配合 Last-Modified）
   • 或 If-None-Match（配合 ETag）
2. 服务器判断资源是否有更新。
   • 如果未更新 → 返回 304 Not Modified（无响应体）。
   • 浏览器直接使用本地缓存资源。
3. 如果资源已修改 → 返回 200 OK + 新资源内容。

重定向区别：302、303、307

它们都表示临时重定向，但语义和请求方式处理不同。

状态码	含义	是否改变请求方法
302 Found	临时重定向（早期定义模糊）	旧浏览器会把 POST 改为 GET
303 See Other	临时重定向到另一个资源	强制改为 GET 请求
307 Temporary Redirect	临时重定向（HTTP1.1 修订）	保持原请求方法（POST 仍为 POST）

• 一句话区分：
  302 历史问题不规范；
  303 明确变 GET；
  307 明确保持原方法。

---

HTTP & HTTPS

HTTP1.0 / HTTP1.1 / HTTP2 / HTTP3 的区别

HTTP/1.0 无复用，1.1 加长连接；
HTTP/2 多路复用 + 二进制 + 压缩；
HTTP/3 基于 QUIC，用 UDP 彻底消除队头阻塞。

HTTP/1.0

• 每次请求都要重新建立 TCP 连接。
• 无法复用连接，性能差。
• 无 Host 头，无法在同一 IP 部署多个站点。

HTTP/1.1

• 长连接（Keep-Alive）：可复用 TCP 连接。
• 管线化（Pipeline）（但实际几乎不用）。
• 增加 Host 头、缓存控制（Cache-Control）、分块传输（Chunked）。
• 同一连接仍 串行阻塞（队头阻塞）。

HTTP/2

• 二进制分帧：取代文本协议，解析更高效。
• 多路复用：一个连接并发多个请求，无阻塞。
• 头部压缩（HPACK），减少冗余传输。
• 服务器推送（Server Push）（现已不推荐）。
• 仍依赖 TCP，丢包会影响所有流。

HTTP/3

• 基于 QUIC 协议（UDP），解决 TCP 队头阻塞。
• 0-RTT 建连，首次后几乎可瞬时连接。
• 内建 加密（TLS 1.3）。
• 更快重传与连接迁移（适合移动网络）。

HTTP2 相对于 HTTP1.x 的优势和特点

1. 二进制分帧
   • HTTP/2 不再使用文本格式，而是使用二进制帧结构传输数据。
   • 优点：解析效率更高、数据更紧凑、出错率更低。
2. 多路复用
   • 在同一个 TCP 连接上可以同时发送多个请求和响应，不会出现队头阻塞。
   • 提高了连接利用率，减少延迟。
3. 头部压缩
   • 使用 HPACK 算法压缩请求头部，避免重复传输大量相同的 Header 信息。
   • 节省带宽，加快请求速度。
4. 服务器推送
   • 服务器可以在客户端请求前主动推送资源，比如在请求 HTML 时提前推送 CSS/JS 文件。
   • 减少首屏等待时间。
5. 请求优先级
   • 客户端可以为不同的请求指定优先级，优化资源加载顺序。
   • 比如：先加载关键渲染资源，再加载图片或非关键脚本。
6. 更高的性能表现
   • 由于头部压缩 + 多路复用 + 二进制传输 + 推送机制，使整体延迟显著降低，尤其在高延迟网络环境中效果更明显。

HTTP 和 HTTPS 的区别

1. 协议端口不同
   • HTTP 默认使用 80 端口，HTTPS 使用 443 端口。
2. 传输安全性不同
   • HTTP 明文传输，容易被中间人窃取或篡改。
   • HTTPS 在 HTTP 之上增加 TLS/SSL 加密，保证数据传输安全。
3. 加密方式
   • HTTPS 使用 对称加密 + 非对称加密 + 数字证书 的组合：
     • 非对称加密协商对称密钥
     • 对称加密实际传输数据
     • 数字证书保证身份真实性
4. 性能开销
   • HTTPS 有握手和加密解密开销，比 HTTP 略慢，但现代硬件和协议优化已基本可忽略。

HTTPS 安全性体现在哪里

1. 加密通信
   • 数据在客户端和服务器之间传输时经过加密（对称 + 非对称），防止被窃听。
2. 身份认证
   • 通过数字证书（CA 颁发）验证服务器身份，防止被伪造或中间人攻击（MITM）。
3. 数据完整性
   • 传输过程中数据会进行完整性校验（如 HMAC），防止被篡改或损坏。

https 数据传输的过程

1. 先建立 TCP 连接（三次握手）。
2. 浏览器告诉服务器自己支持哪些加密方式。
3. 服务器回应并发来证书（里面有公钥）。
4. 浏览器验证证书是否合法、域名是否匹配。
5. 浏览器生成一个随机密钥，用服务器的公钥加密后发过去。
6. 服务器用私钥解密，得到同样的密钥。
7. 后续数据传输都用这个密钥进行对称加密，保证安全高效。

什么是 HTTPS 协议？如何加密？

HTTPS是基于 HTTP + TLS/SSL 的安全传输协议，用于在网络上加密传输数据，保证通信安全。

加密方式：

1. 非对称加密
   • 用于身份验证和密钥交换。
   • 客户端使用服务器公钥加密随机生成的对称密钥，服务器用私钥解密。
2. 对称加密
   • 用于实际的数据传输。
   • 建立好共享的对称密钥后，数据以对称加密方式快速传输。
3. 数字证书
   • 由 CA 颁发，保证服务器身份真实可靠。

加密过程：

1. 服务器发送证书
   • 服务器将 CA 颁发的数字证书（包含公钥）发送给浏览器。
2. 浏览器验证证书
   • 浏览器验证证书合法性（CA 签名、有效期等），拿到服务器公钥。
3. 生成对称密钥并加密
   • 浏览器生成随机对称密钥，用服务器公钥加密后发送给服务器。
4. 服务器解密
   • 服务器用私钥解密，得到浏览器发送的对称密钥。
5. 对称加密通信
   • 后续客户端和服务器使用这个对称密钥进行加密数据传输。

TLS/SSL 工作原理

1. 身份认证
   • 服务器提供 数字证书（CA 颁发），浏览器验证证书是否合法，确认服务器身份。
2. 密钥协商
   • 非对称加密用于安全地交换对称密钥。
   • 浏览器生成对称密钥，用服务器公钥加密后发送，服务器用私钥解密得到对称密钥。
3. 加密通信
   • 协商好的对称密钥用于后续 数据传输的加密和解密，保证机密性和传输效率。
4. 完整性校验
   • 数据传输过程中通过 MAC（消息认证码） 或哈希校验，确保数据未被篡改。

HTTP 中的 keep-alive

Keep-Alive 让同一个 TCP 连接可复用多个请求，减少握手次数和资源消耗，提高性能。

概念：

• Keep-Alive（持久连接）是 HTTP/1.1 默认特性，用来 在同一个 TCP 连接上发送和接收多个请求/响应，避免为每个请求都建立新连接。

作用 / 优势：

1. 减少 TCP 握手次数，降低延迟。
2. 降低 网络资源消耗，提升性能。
3. 便于 HTTP/1.x 的管线化请求。

使用方式：

• HTTP/1.0：需在请求头或响应头中加 Connection: Keep-Alive
• HTTP/1.1：默认开启，可用 Connection: close 显式关闭

---

浏览器工作机制

从输入 URL 到页面加载的全过程

1. URL 解析 & DNS 解析
   • 浏览器根据输入的域名，先查本地缓存、系统缓存、DNS 服务器，解析出目标服务器的 IP 地址。
2. TCP 连接（三次握手）
   • 客户端与服务器建立 TCP 连接（若是 HTTPS，还会进行 TLS 握手，建立安全信道）。
3. 发送 HTTP 请求
   • 浏览器发送请求报文（包括请求头、cookie 等）到服务器。
4. 服务器处理请求并返回响应
   • 服务器返回响应头和响应体（如 HTML、CSS、JS、图片等资源）。
5. 浏览器接收响应并解析资源
   • 浏览器开始解析 HTML，构建 DOM 树。
   • 下载并解析 CSS，构建 CSSOM 树。
   • 两者合并成 Render Tree（渲染树）。
6. 布局（Layout）和绘制（Paint）
   • 浏览器根据渲染树计算各元素位置（Layout），再绘制到屏幕上（Paint），最终合成图层（Composite）。
7. JS 执行与页面交互
   • 下载并执行 JS，可能会修改 DOM 或样式，触发重绘/回流。
   • 页面进入可交互阶段。

Socket 连接步骤

1. 客户端和服务端各自创建 Socket；
2. 服务端绑定端口并开始监听；
3. 客户端发起连接请求，经过 TCP 三次握手 建立连接；
4. 双方通过 Socket 进行数据读写；
5. 通信结束后，通过 四次挥手 关闭连接。

DNS 协议 & 域名解析过程

DNS 协议：是把域名解析成 IP 地址的协议。因为人容易记域名、计算机只认 IP。

域名解析过程：

1. 浏览器先查 本地缓存；
2. 如果没有，再查 操作系统缓存（host 文件）；
3. 还没找到，就向 本地 DNS 服务器（一般是运营商）发请求；
4. 若本地 DNS 没缓存，它会进行递归或迭代查询，依次问：
   • 根域名服务器（.）
   • 顶级域名服务器（.com）
   • 权威域名服务器（example.com）
5. 权威服务器返回目标 IP；
6. 本地 DNS 缓存结果并返回给浏览器；
7. 浏览器拿到 IP 后，发起 TCP 连接。

浏览器渲染 UI 过程

1. 解析 HTML → 构建 DOM 树
2. 解析 CSS → 构建 CSSOM 树
3. 合并 DOM 和 CSSOM → 生成 Render Tree（渲染树）
4. **布局：**计算每个节点的大小、位置等几何信息。
5. **绘制：**将渲染树的各节点绘制到图层上。
6. **合成：**GPU 将多个图层合成为最终页面，并展示在屏幕上。

浏览器渲染阻塞问题

1. HTML 解析是顺序执行的，遇到外部资源（如 CSS、JS）会影响渲染。
2. CSS 会阻塞渲染，因为在样式没下载并解析完前，浏览器无法确定元素的最终样式，渲染树不能完整生成。
3. JS 会阻塞 HTML 解析，因为脚本可能修改 DOM 或样式，浏览器必须等脚本执行完再继续解析。

优化方式：

• CSS：放在 <head>，减少阻塞首屏渲染。
• JS：放在页面底部或使用 defer / async 属性。
• 合理拆分首屏关键资源，使用懒加载和预加载。

DOM Tree 构建

1. 读取 HTML 字节流 → 转为字符流
   • 浏览器网络线程接收 HTML 文件数据，并交给解析器处理。
2. 词法分析 → 生成 Token（标记）
   • HTML 解析器将字符串拆成一个个 Token，比如开始标签、结束标签、文本节点等。
3. 语法分析 → 构建节点对象
   • 根据 Token 的层级关系，创建对应的 DOM 节点对象。
4. 逐步构建成 DOM 树
   • 按照标签的嵌套结构，父子节点形成树状结构。
   • 这个过程是边下载边解析边构建的。

浏览器有哪些进程

• 主进程：负责处理用户输入、渲染页面等主要任务
• 渲染进程：负责解析 HTML、CSS 和 JS，并将网页渲染成可视化内容
• GPU 进程：负责处理浏览器中的 GPU 加速任务
• 网络进程：网络进程负责处理浏览器中的网络请求和响应，包括下载网页和资源等
• 插件进程：负责浏览器插件运行

---

前端存储 & 安全

浏览器中的同源策略（跨域）

概念：

• 同源策略是一种浏览器安全机制，用于限制不同源的脚本互相访问数据，防止跨站攻击（XSS/CSRF）。
• 同源判断标准：协议 + 域名 + 端口 都相同，才算同源。

影响范围：

• 跨源的 DOM 访问 被禁止。
• 跨源的 Cookie、LocalStorage、IndexedDB 默认不可访问。
• AJAX 请求默认受限（除非服务器设置 CORS 允许）。

解决方法 / 常见场景：

1. CORS（跨域资源共享）：服务器在响应头设置 Access-Control-Allow-Origin 等允许跨域。
2. JSONP：通过 <script> 标签请求跨域资源（仅限 GET）。
3. Proxy / 网关：前端请求同源服务器，由服务器代理请求目标接口。

HttpOnly

概念：

• HttpOnly 是 Cookie 的一个属性，用来 禁止客户端 JavaScript 访问该 Cookie。

作用：

• 防止 XSS 攻击窃取敏感 Cookie（如登录凭证、Session ID）。
• Cookie 仍会随 HTTP 请求自动发送给服务器，但 JS 脚本无法读取或修改。

localStorage / sessionStorage / cookie 的区别

特性	cookie	localStorage	sessionStorage
存储大小	~4KB	510MB	510MB
生命周期	可设置过期时间；默认随浏览器关闭清除	永久，除非手动清除	会话级，浏览器窗口关闭即清除
发送给服务器	每次请求都会带上	不会	不会
作用域	域名	域名	窗口/标签页会话
安全性	可设置 HttpOnly（JS 无法访问），易被 XSS 攻击	JS 可访问	JS 可访问

• cookie：小、会随请求发送、可做登录凭证。
• localStorage：本地永久存储、大容量、不随请求发送。
• sessionStorage：本地会话存储、关闭窗口即清空，不随请求发送。

怎么禁止 JS 访问 cookie

1. 设置 HttpOnly（最推荐）
   • 在服务器端设置 Cookie 时加上 HttpOnly 属性，JS 无法读取或修改，浏览器自动随 HTTP 请求发送。
2. 通过 JS 限制（不完全安全）
   • 可以通过前端策略限制对 document.cookie 的访问，但仍可能被恶意脚本绕过。
3. 动态覆盖或删除
   • 在 JS 中设置同名 Cookie 覆盖或删除，但同样只能操作非 HttpOnly 的 Cookie。

cookie 的属性

属性	作用
name=value	Cookie 名和值，必填
Domain	指定可访问该 Cookie 的域名（默认当前域名）
Path	指定可访问该 Cookie 的路径（默认 /）
Expires / Max-Age	设置 Cookie 生命周期，过期后自动删除
Secure	仅在 HTTPS 连接中传输 Cookie
HttpOnly	禁止 JS 访问 Cookie，防止 XSS 窃取
SameSite	限制跨站请求发送 Cookie，可选 Strict / Lax / None，防止 CSRF 攻击

WEB 安全常见问题（XSS、CSRF、点击劫持等）

1. XSS（跨站脚本攻击）

• 概念：攻击者在页面注入恶意脚本，窃取 Cookie、篡改 DOM 等。
• 防护：对用户输入做 转义/过滤，使用 Content Security Policy（CSP），敏感 Cookie 加 HttpOnly。

2. CSRF（跨站请求伪造）

• 概念：攻击者诱导用户浏览器发起跨站请求，执行未授权操作。
• 防护：使用 CSRF Token、检查 Referer/Origin，设置 Cookie SameSite 属性。

3. SQL 注入

• 概念：攻击者通过在输入中注入 SQL 语句，篡改数据库操作。
• 防护：使用 参数化查询 / ORM，不要拼接 SQL。

4. 点击劫持（Clickjacking）

• 概念：通过 iframe 或透明层诱导用户点击恶意按钮。
• 防护：使用 X-Frame-Options 或 CSP 的 frame-ancestors 限制嵌套。

5. 敏感信息泄露

• 概念：明文传输敏感数据，或错误配置导致数据泄露。
• 防护：使用 HTTPS / TLS 加密，避免在 URL 中传密码，限制日志打印敏感信息。

6. 认证与会话管理问题

• 防护：Cookie 使用 HttpOnly + Secure + SameSite，Session ID 定期刷新，使用强随机值。

---

并发与网络协议

进程、线程、协程的区别

1. 进程
   • 操作系统分配资源的基本单位。
   • 有独立的内存空间、堆栈和资源。
   • 进程之间切换开销大，通信相对复杂（IPC）。
2. 线程
   • 进程的执行单位，同一进程内的线程共享内存和资源。
   • 切换开销比进程小，通信方便。
3. 协程
   • 用户态轻量级“线程”，由程序自己调度（非操作系统调度）。
   • 同一线程内可以并发执行多个协程，切换非常快。
   • 常用于异步 IO、事件驱动模型（如 JS 的 async/await）。

三次握手和四次挥手

三次握手（建立 TCP 连接）

目的：双方确认连接可用，协商初始序列号。

步骤：

1. SYN：客户端发送 SYN 报文，表示请求建立连接。
2. SYN-ACK：服务器收到 SYN，回复 SYN+ACK，确认收到请求并同意连接。
3. ACK：客户端收到 SYN+ACK，回复 ACK，连接建立完成。

四次挥手（关闭 TCP 连接）

目的：双方可靠关闭连接，确保剩余数据发送完成。

步骤：

1. FIN：一方（客户端）主动关闭连接，发送 FIN。
2. ACK：另一方（服务器）确认收到 FIN。
3. FIN：服务器准备关闭连接，发送 FIN。
4. ACK：客户端确认收到 FIN，连接完全关闭。

TCP/IP 五层协议 & OSI 七层模型

TCP 和 UDP 的区别

特性	TCP	UDP
连接方式	面向连接（三次握手）	无连接
可靠性	保证可靠传输，丢包重传	不保证可靠性，可能丢包
顺序保证	数据按顺序到达	不保证顺序
传输方式	面向字节流	面向报文（Datagram）
头部开销	较大（20 字节）	较小（8 字节）
适用场景	文件传输、网页加载、邮件	视频直播、在线游戏、DNS 查询

---

身份认证与授权

如何标识用户已经登录？

登录标识通常依靠 Cookie + Session 或 Token（如 JWT） 来维持用户身份； 前端保存凭证，后端验证有效性，从而判断用户是否已登录。

Cookie + Session（传统方案）

• 登录后：服务端创建 session，生成唯一 sessionId，写入 Cookie。
• 后续请求：浏览器自动携带 Cookie，服务端根据 sessionId 找回登录状态。
• 特点：安全、简单，适合传统 Web（服务端渲染）。

Token（现代前后端分离常用）

• 登录后：服务端签发 Token（常见是 JWT），前端存储在 localStorage 或 Cookie。
• 请求时：前端在请求头加上 Authorization: Bearer token。
• 服务端验证：校验 Token 有效性，确认用户身份。
• 特点：无状态、可跨域，适合前后端分离。

第三方登录 / SSO

• 使用 OAuth2 / OpenID Connect 等协议。
• 登录后颁发访问令牌，和 Token 机制类似。
• 常见于企业登录（如钉钉登录、Google 登录等）。

SSO 单点登录

• 概念：用户只需登录一次，就可以访问多个系统或服务，无需重复登录。
• 原理：中心认证服务器发放统一 Token（如 Cookie 或 JWT），各应用系统验证 Token 来允许访问。

JWT

• 概念：一种轻量级的、可跨域使用的身份认证 Token，包含用户信息和签名。
• 结构：Header.Payload.Signature

1. Header：算法信息
2. Payload：存放用户信息、权限等
3. Signature：用密钥或私钥签名，防篡改

• 特点：自包含、无状态、可用于分布式系统。

OAuth 2

• 概念：授权框架，用于第三方应用访问用户资源，而无需直接获取用户密码。
• 流程：

1. 用户在资源服务器授权客户端
2. 客户端获得授权码（Authorization Code）
3. 用授权码换取访问 Token
4. 用 Token 访问资源服务器

• 特点：安全、标准化、常用于社交登录（微信、GitHub、Google 登录）。

Token 相关

Token 过期如何刷新？

使用 Refresh Token 机制。

• 登录时，服务端返回两个令牌：
  • Access Token：短期有效（如 2 小时）；
  • Refresh Token：长期有效（如 7 天）。
• 当 Access Token 过期：
  1. 前端检测到 401（未授权）；
  2. 使用 Refresh Token 调用刷新接口；
  3. 后端验证后签发新的 Access Token。

如何无感刷新 Token？

• 在请求前或响应时检测 Token 是否即将过期；
• 若快过期，提前调用刷新接口；
• 刷新完成后自动重发原请求；
• 用户界面无跳转、无感知。

上述逻辑写在哪里？

写在 请求响应拦截层。

具体做法：

• 请求拦截器：在请求头统一添加 Authorization: Bearer token；
• 响应拦截器：捕获 401；
  • 若存在 Refresh Token，自动发起刷新；
  • 刷新成功后重试原请求；
  • 刷新失败则清除登录状态并跳转登录页。

响应拦截器的功能

• 统一错误提示（如 401、403、500）
• 自动刷新 Token 或跳转登录
• 数据统一解包（取 res.data）
• 全局 Loading / Toast 管理

---

浏览器内核

常见浏览器内核

浏览器	内核
Chrome / Edge / Opera	Blink（Chromium 基础）
Safari	WebKit
Firefox	Gecko
IE（Internet Explorer）	Trident
旧版 Opera（Presto）	Presto

---

• 【前端面试】HTML篇
• 【前端面试】CSS篇
• 【前端面试】JS篇
• 【前端面试】Vue篇
• 【前端面试】Git篇
• 【前端面试】前端工程化篇
• 【前端面试】手写题篇
• 【前端面试】前端性能优化篇
• 【前端面试】浏览器&网络篇

整理不易，有回答错误之处欢迎在评论区指正交流~