以下是某独角兽的前端一面面试题，将近两个小时的面试。下面简单总结一下，大家也可以自测一下相关知识点。

1. 项目介绍及技术栈

项目描述：介绍自己做过的项目

技术栈:

• 前端: React Native（用于构建跨平台的移动端应用），Redux（状态管理），React Navigation（路由管理），Styled-components（样式组件化）。vue同样去讲一下相关生态技术即可。
• 后端: Node.js（Express框架），MongoDB（数据库）
• 其他: Webpack（模块打包），vite

2. 移动端平台判断

在移动端开发中，通常使用navigator.userAgent字符串来判断设备平台。通过解析这个字符串，可以识别出是Android、iOS还是微信内置浏览器。此外，也可以使用第三方库如react-native-device-info（React Native环境下）来简化这一过程。

3. 移动端页面尺寸和宽高处理

在设计移动端页面时，一般遵循响应式设计原则，使用视口单位（vw/vh）、百分比或Flexbox布局来处理页面的尺寸和宽高。同时，使用媒体查询（Media Queries）来适配不同屏幕尺寸的设备。对于React Native，则利用平台的样式系统（如StyleSheet.create）和布局组件（如View、Text、Image等）来构建适应不同屏幕尺寸的界面。

4. Rem值计算和适配方式

根据设计稿的尺寸计算rem值，通常需要先设定一个基准宽度（如设计稿宽度为750px），然后基于这个宽度将设计稿中的px值转换为rem值。例如，如果基准宽度为750px，且html的font-size设置为100px（即1rem=100px），则设计稿中宽度为150px的元素，其rem值为1.5rem。

目前移动端适配方式除了rem布局外，还有vw/vh布局、百分比布局、Flexbox布局、Grid布局以及使用PostCSS插件（如postcss-pxtorem）自动转换px到rem等。

5. React函数式组件的应用周期

在React函数式组件中，组件的调用通常发生在以下几个阶段：

• 首次渲染时。
• 组件的props或state变化时（如果组件依赖于这些变化）。
• 父组件重新渲染时（但这不一定会导致子组件重新渲染，除非子组件的props或state变化，或者使用了不纯的函数）。

函数被调用的次数取决于上述事件发生的次数以及组件的优化程度（如使用React.memo、useMemo、useCallback等）。

6. React组件更新触发条件

React组件会在以下情况下触发更新：

• 组件的props发生变化。
• 组件的state发生变化。
• 组件的父组件重新渲染，且传递给该组件的props发生变化（或子组件使用了不纯的函数，导致即便props未变也重新渲染）。
• 组件内部调用了forceUpdate方法（通常不推荐使用，因为它会跳过shouldComponentUpdate和React.memo的优化）。

7. 子组件重新渲染问题

如果子组件没有接收任何props，父组件渲染时，子组件可能会跟着重新渲染，但这取决于子组件的实现。如果子组件内部有状态（state）或副作用（如useEffect），并且这些状态或副作用的依赖项没有变化，那么子组件可能不会进行不必要的重新渲染（尽管其函数体可能会被调用）。然而，如果子组件的实现不够优化（如使用了不纯的函数），则每次父组件渲染时，子组件都会重新渲染。

8. React.memo的作用及处理机制

React.memo是一个高阶组件，用于对函数式组件进行记忆化。它仅对props进行浅比较，如果props没有变化，则不会重新渲染组件，而是返回上一次的渲染结果。这有助于避免在父组件重新渲染时，不必要的子组件重新渲染。

9. JSX编译结果

组件返回的JSX在编译阶段会被转换成React.createElement的调用。例如，<div>Hello, World!</div>会被转换成React.createElement('div', null, 'Hello, World!')。这样做是为了在JavaScript环境中构建虚拟DOM树，并最终由React的渲染引擎将虚拟DOM转换为真实的DOM。

10. React函数式组件中的hooks写法规范

React函数式组件中的hooks需要遵循以下写法规范：

• 只能在函数组件的顶层调用Hooks（不能在循环、条件或嵌套函数中调用）。
• 遵循命名约定，如使用use前缀（useState、useEffect等）。
• 确保Hooks的调用顺序在每次渲染时保持一致，以便React能够正确地将Hooks与组件的状态关联起来。

这些规范是出于React内部实现机制的考虑。React通过Hooks的顺序来追踪组件的状态和副作用，因此如果Hooks的调用顺序在组件的不同渲染之间发生变化，可能会导致状态丢失或不可预测的行为。

11. React Fiber的诞生背景及解决的问题

React Fiber是在React 16中引入的，它的诞生背景是为了解决React在动画、布局、手势操作等场景下性能不足的问题。Fiber是一个新的协调引擎，它重新实现了React的核心算法，使得React能够更高效地处理组件的更新、渲染和卸载。

Fiber旨在解决的主要问题包括：

• 增量渲染：允许React将渲染工作拆分成多个小任务，并在多个帧中完成，从而避免长时间占用主线程，提高应用的响应性和流畅度。
• 优先级分配：为不同类型的任务分配不同的优先级，确保重要的任务（如用户交互）能够优先处理。
• 暂停、恢复和重用：允许React在任务执行过程中暂停和恢复，以及在多个渲染之间重用之前的工作成果，进一步提高性能。

12. React自动优化方案

除了手动优化（如使用React.memo、useMemo、useCallback等），React还提供了以下自动优化方案：

• 代码分割（Code Splitting）：通过Webpack等打包工具将应用拆分成多个代码块，并在需要时动态加载，以减少初始加载时间。
• 懒加载（Lazy Loading）：React Suspense和React.lazy允许你以声明式的方式在组件级别进行代码分割和懒加载。
• 服务端渲染（SSR）和预渲染（Pre-rendering）：通过服务端或构建时生成静态页面，以减少客户端的渲染时间和数据量。
• React Fast Refresh：在开发环境中，React Fast Refresh可以更快地重新加载更改的组件，而无需完全刷新页面，从而提高开发效率。

13. 服务端渲染（SSR）

a. 项目经验和框架

如果有服务端渲染的项目经验，通常会使用React的SSR库如Next.js或Gatsby。这些框架提供了内置的SSR支持，简化了开发过程。

b. 服务端渲染原理

服务端渲染的原理是在服务器上执行React组件，生成HTML字符串，然后将这个字符串发送给客户端浏览器。这样，用户首次访问页面时就可以立即看到完整渲染的页面，而无需等待JavaScript执行和DOM构建。

c. 服务端处理

服务端需要做以下处理才能生成DOM结构：

• 解析请求，获取需要渲染的页面或数据。
• 在服务器上执行React组件，生成虚拟DOM。
• 将虚拟DOM转换为HTML字符串。
• 将HTML字符串作为响应发送给客户端。

14. Vue响应式实现及依赖收集

Vue的响应式系统是基于ES5的Object.defineProperty（在Vue 3中使用了Proxy）来实现的。当一个响应式数据（如组件的data属性）被访问或修改时，Vue会拦截这些操作，并触发依赖更新。

依赖收集的过程如下：

• 当组件的模板或计算属性等依赖于某个响应式数据时，Vue会将这些依赖收集起来。
• 当响应式数据变化时，Vue会遍历这些依赖，并通知它们进行更新。
• 组件重新渲染，更新DOM以反映最新的数据状态。

15. React和Vue性能差异

React和Vue在性能方面各有优势，但通常差异不大，具体取决于应用的复杂度、优化程度以及使用的特定功能和库。

一些可能的差异包括：

• React的Fiber架构允许更细粒度的更新和更好的性能优化。
• Vue的响应式系统在某些情况下可能更直接和高效，因为它在数据变化时直接通知依赖，而不需要像React那样通过虚拟DOM进行比对。
• React的Hooks和Context API提供了更灵活的状态管理和跨组件通信方式，但也可能增加复杂度。

16. React中实现类似Vue computed属性的功能

在React中，可以使用useMemo或自定义的Hook来实现类似Vue computed属性的功能。useMemo可以缓存一个复杂计算的结果，并在依赖项发生变化时重新计算。通过封装useMemo，可以创建一个自定义Hook来模拟computed属性的行为。

17. 其他编程语言知识

我了解并熟悉多种编程语言，包括Java、Python、C++等。这些语言在各自的应用领域都有广泛的使用，并且它们的学习有助于拓宽我的技术视野和提高解决问题的能力。

18. 进程和线程概念

进程：是系统进行资源分配和调度的一个独立单元，它是应用程序运行的载体。每个进程都有独立的内存空间和系统资源。

线程：是进程的一个实体，是CPU调度和分派的基本单位，它是进程中的实际运作单位。线程是操作系统能够进行运算调度的最小单位，它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。

进程与线程的主要区别：

1. 资源占用：进程是资源分配的基本单位，它拥有独立的内存空间和系统资源。而线程是CPU调度的基本单位，它共享进程的资源，包括内存、文件句柄等。

2. 独立性：进程是独立运行的程序，拥有独立的地址空间，而线程是进程中的一个实体，它不能独立运行，必须依赖于所属的进程。

3. 开销：由于进程拥有独立的资源，因此进程间的切换需要保存和恢复较多的上下文信息，开销较大。而线程切换的开销较小，因为它们是共享进程的资源的。

4. 通信：进程间的通信较为复杂，需要通过IPC（进程间通信）机制来实现。而线程间的通信则相对简单，因为它们共享进程的内存空间，可以直接读写共享变量。

5. 并发性：多线程的并发性更高，因为它们是共享同一进程的资源的，可以在同一进程中并发执行多个任务。而多进程虽然也可以实现并发，但每个进程都需要独立的资源，因此并发性较低。

19. 浏览器事件循环

浏览器的事件循环是JavaScript执行的基础，它允许JavaScript代码在浏览器环境中异步执行。浏览器的事件循环主要包括以下几个部分：

1. 调用栈（Call Stack）：JavaScript引擎用调用栈来跟踪函数执行。当代码执行时，它被压入调用栈，并在执行完毕后从栈中弹出。

2. 事件队列（Event Queue）：当异步事件（如点击事件、定时器到时等）发生时，它们会被放入事件队列中等待处理。

3. 事件循环（Event Loop）：事件循环不断检查调用栈是否为空，并且事件队列中是否有待处理的事件。如果调用栈为空，事件循环会从事件队列中取出一个事件，并将其对应的回调函数放入调用栈中执行。

这个过程会不断重复，形成了浏览器的事件循环。它允许JavaScript代码在等待异步操作完成时，不会阻塞UI的渲染和其他任务的执行。

20. 浏览器渲染流程

浏览器的渲染流程主要包括以下几个步骤：

1. 解析HTML：浏览器将HTML文档解析成DOM树。

2. 构建CSSOM：浏览器解析CSS文件，构建CSSOM（CSS Object Model）树。

3. 合并DOM树和CSSOM树：浏览器将DOM树和CSSOM树合并成一个渲染树（Render Tree）。渲染树只包含需要显示的节点和样式信息。

4. 布局（Layout）：浏览器根据渲染树计算每个节点的几何信息，如位置和大小。

5. 绘制（Paint）：浏览器将渲染树的节点绘制到屏幕上。这一步会生成绘制层（Paint Layers），并填充像素信息。

6. 合成（Compositing）：浏览器将多个绘制层合并成一个或多个图像，然后显示在屏幕上。如果页面中有动画或滚动，浏览器会重新执行布局、绘制和合成步骤来更新屏幕显示。

这个过程是浏览器渲染网页的基本流程，它确保了网页能够正确地显示在用户的屏幕上。### 21. HTTP和HTTPS的区别

HTTP（HyperText Transfer Protocol）和HTTPS（HyperText Transfer Protocol Secure）是两种用于在网络上传输数据的协议，它们之间有几个关键的区别：

1. 安全性：

• HTTP：是一种不加密的协议，传输的数据（包括用户名、密码等敏感信息）容易被窃听或篡改。
• HTTPS：是HTTP的安全版本，它使用SSL/TLS协议对数据进行加密，确保数据在传输过程中的安全性。

2. 端口号：

• HTTP：默认使用TCP的80端口。
• HTTPS：默认使用TCP的443端口。

3. URL前缀：

• HTTP：URL以http://开头。
• HTTPS：URL以https://开头。

4. 性能：

• HTTPS由于需要进行加密和解密操作，相对于HTTP来说会有一定的性能开销。然而，随着硬件和加密算法的改进，这个差距正在逐渐缩小。

5. 证书：

• HTTPS需要服务器安装SSL/TLS证书，证书由可信的证书颁发机构（CA）签发，用于验证服务器的身份。
• HTTP则不需要证书。

6. 应用场景：

• HTTPS：由于安全性较高，通常用于需要保护用户隐私和敏感信息的场景，如在线购物、网上银行等。
• HTTP：适用于对安全性要求不高的场景，如简单的网页浏览、图片下载等。

22. HTTP/1.x 和 HTTP/2 的主要区别

HTTP/1.x 和 HTTP/2 是HTTP协议的两个不同版本，它们之间存在多个主要区别：

1. 二进制协议：

• HTTP/1.x：基于文本的协议，使用ASCII码传输。
• HTTP/2：采用二进制格式传输数据，这有助于减少传输过程中的解析成本，并提高传输效率。

2. 多路复用（Multiplexing）：

• HTTP/1.x：每个TCP连接只能处理一个请求-响应过程，导致多个请求需要排队等待。
• HTTP/2：支持在同一TCP连接上并行处理多个请求和响应，显著提高了传输效率和性能。

3. 头部压缩（Header Compression）：

• HTTP/1.x：头部信息未经压缩，每次请求都会重复发送相同的头部，造成不必要的带宽浪费。
• HTTP/2：使用HPACK算法对头部信息进行压缩，减少了头部数据的体积，提高了传输效率。

4. 服务器推送（Server Push）：

• HTTP/1.x：不支持服务器主动向客户端推送数据。
• HTTP/2：允许服务器在客户端请求某个资源时，主动推送与当前请求相关的其他资源到客户端，减少了额外的网络请求。

5. 性能改进：

• HTTP/2 在多个方面进行了优化，如减少TCP连接次数、优化数据传输流程等，从而提高了整体的网络性能和用户体验。

23. 浏览器的同源策略及其作用

浏览器的同源策略（Same-Origin Policy）是一种安全策略，它限制了来自不同源的文档或脚本对当前文档读取或设置某些属性时的权限。这里的“源”指的是协议、域名和端口号三者的组合。

作用：

1. 防止跨站请求伪造（CSRF）：CSRF攻击允许攻击者诱使用户在不知情的情况下对受信任的网站执行操作。同源策略可以阻止第三方网站向受信任网站发送请求，从而减轻CSRF攻击的风险。

2. 防止数据泄露：通过限制不同源之间的交互，同源策略可以防止恶意网站读取或修改来自其他网站的敏感数据。

3. 维护用户隐私：同源策略确保了用户数据只在用户明确信任的网站之间共享，从而保护了用户的隐私。

然而，有时候我们需要在不同源之间共享数据或功能，这时可以通过跨域资源共享（CORS）、JSONP、代理服务器等技术来实现。### 24. CORS（跨源资源共享）

CORS（Cross-Origin Resource Sharing）是一种机制，它使用额外的HTTP头部来告诉浏览器允许一个网页运行的脚本从不同于它自身来源的服务器上请求资源。这解决了由同源策略引起的跨域请求问题。

CORS的工作原理：

1. 预检请求（Preflight Request）：对于某些类型的跨域请求（如PUT、DELETE、或包含自定义HTTP头部的GET/POST请求），浏览器会首先发送一个OPTIONS请求到服务器，询问服务器是否允许跨域请求。这个OPTIONS请求被称为“预检请求”。

2. 服务器响应：服务器在接收到预检请求后，会检查请求的源（Origin）是否在自己的允许列表中。如果是，服务器会返回一个包含适当CORS头部的响应，指示浏览器继续执行实际的请求。

3. 实际请求：一旦浏览器收到包含适当CORS头部的响应，它就会继续发送实际的请求。

4. 浏览器处理响应：浏览器会检查响应中的CORS头部，以确定是否应该将响应数据暴露给前端JavaScript代码。

CORS相关的HTTP头部：

• Access-Control-Allow-Origin：指定哪些网站可以参与跨站请求。
• Access-Control-Allow-Methods：指定允许跨站请求的方法。
• Access-Control-Allow-Headers：指定允许跨站请求中携带的自定义头部。
• Access-Control-Expose-Headers：指定哪些头部信息可以安全地暴露给前端JavaScript代码。
• Access-Control-Max-Age：指定预检请求的结果可以被缓存多久。

25. 浏览器缓存机制

浏览器缓存机制是一种减少服务器请求、加快页面加载速度的技术。它通过缓存静态资源（如HTML、CSS、JavaScript、图片等）到客户端（浏览器），并在后续请求中直接使用缓存资源，而不是重新从服务器加载。

浏览器缓存的几种类型：

1. 强缓存（Cache-Control/Expires）：

• 当请求的资源满足缓存条件时，浏览器直接从缓存中读取资源，不会向服务器发送请求。
• Cache-Control 和 Expires 是控制强缓存的HTTP头部。

2. 协商缓存（Last-Modified/If-Modified-Since/ETag/If-None-Match）：

• 浏览器首先检查缓存中的资源是否过期，如果未过期则直接使用缓存资源。
• 如果资源已过期，浏览器会向服务器发送带有条件请求头部的请求（如 If-Modified-Since 或 If-None-Match），询问资源自上次请求后是否有修改。
• 服务器根据请求头部的条件，判断资源是否有修改，并返回相应的响应。

浏览器缓存的优点：

• 加快页面加载速度，提升用户体验。
• 减少服务器负载和带宽消耗。

浏览器缓存的缺点：

• 可能导致用户看到的内容不是最新的。
• 需要合理设置缓存策略，以避免不必要的缓存或缓存失效。### 26. HTTP状态码

HTTP状态码（HTTP Status Code）是服务器用来表示网页服务器HTTP响应状态的3位数字代码。这些状态码被分成五类，以指示请求的结果或错误。

HTTP状态码的分类：

1. 1xx（信息性状态码）：表示接收到请求，正在处理。

• 100 Continue：客户端应当继续发送请求。
• 101 Switching Protocols：服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。

2. 2xx（成功状态码）：表示请求已成功被服务器接收、理解、并接受。

• 200 OK：请求成功。
• 201 Created：请求已经被实现，而且有一个新的资源已经按照请求的需求被创建。
• 202 Accepted：服务器已接受请求，但尚未处理。

3. 3xx（重定向状态码）：表示需要客户端采取进一步的操作才能完成请求。

• 301 Moved Permanently：请求的资源已永久移动到新位置。
• 302 Found：请求的资源现在临时从不同的URI响应请求。
• 304 Not Modified：自从上次请求后，请求的网页未修改过。

4. 4xx（客户端错误状态码）：表示请求包含语法错误或无法完成请求。

• 400 Bad Request：服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。
• 401 Unauthorized：请求未授权。
• 403 Forbidden：服务器理解请求客户端的请求，但是拒绝执行此请求。
• 404 Not Found：服务器无法根据客户端的请求找到资源（网页）。

5. 5xx（服务器错误状态码）：表示服务器在处理请求的过程中发生了错误。

• 500 Internal Server Error：服务器遇到了一个未曾预料到的情况，导致了它无法完成对请求的处理。
• 502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
• 503 Service Unavailable：由于临时的服务器维护或者过载，服务器当前无法处理请求。

27. 浏览器安全策略

浏览器安全策略是一系列旨在保护用户免受网络攻击和恶意软件侵害的措施。这些策略包括但不限于：

1. 同源策略（SOP）：如前所述，限制来自不同源的文档或脚本对当前文档读取或设置某些属性时的权限。

2. 内容安全策略（CSP）：通过HTTP头部告诉浏览器哪些外部资源是允许的，从而减少XSS（跨站脚本）攻击的风险。

3. X-Frame-Options：防止网站被嵌入到frame或iframe中，从而避免点击劫持攻击。

4. X-Content-Type-Options：防止浏览器尝试基于响应的实体内容去“嗅探”并忽略响应的Content-Type头部。这有助于减少基于MIME类型混淆的攻击。

5. X-XSS-Protection：尽管现代浏览器已不再推荐使用（因为现代浏览器内置了更强大的XSS防护机制），但X-XSS-Protection头部曾用于启用或禁用浏览器的XSS过滤器。

6. HTTP Strict Transport Security（HSTS）：通过HTTP头部告诉浏览器仅通过HTTPS与服务器通信，增加通信的安全性。

7. 公共密钥基础设施（PKI）和SSL/TLS证书：用于加密HTTPS通信，确保数据传输的机密性和完整性。

8. Cookie安全属性：如HttpOnly和Secure属性，用于减少跨站脚本（XSS）和中间人攻击（MITM）的风险。

这些安全策略共同构成了现代Web应用安全的基石，帮助保护用户数据和隐私免受威胁。### 28. Web API 和 RESTful API

Web API（Web Application Programming Interface）是一种允许不同软件应用程序之间通信的接口。它使用HTTP协议，通过请求和响应的方式，在不同的系统或应用之间交换数据。Web API可以支持多种数据格式，如JSON、XML等，以便不同的客户端（如Web浏览器、移动应用、桌面应用等）都能方便地与之交互。

RESTful API（Representational State Transfer）是一种设计Web API的架构风格，而不是一个协议或标准。RESTful API遵循REST原则，强调资源的表示、状态转移和客户端-服务器模型。RESTful API使用HTTP方法（如GET、POST、PUT、DELETE等）来操作资源，每个方法都对应着对资源的特定操作。例如，GET方法用于获取资源，POST方法用于创建资源，PUT方法用于更新资源，DELETE方法用于删除资源。

RESTful API的特点：

1. 无状态（Stateless）：服务器不会保存客户端的状态信息，每次请求都是独立的，包含了服务器所需的所有信息。

2. 可缓存（Cacheable）：客户端可以缓存响应数据，以减少服务器负载和网络带宽消耗。

3. 分层系统（Layered System）：客户端无法直接知道它是否与最终的服务器进行交互，还是通过中间层（如负载均衡器、代理服务器等）进行交互。

4. 统一接口（Uniform Interface）：客户端和服务器之间通过标准的HTTP方法和头部进行通信，使得不同的系统和服务能够相互通信。

5. 资源导向（Resource-Oriented）：RESTful API将网络上的所有内容都视为资源，并使用URI来定位资源。

RESTful API与Web API的关系：

• RESTful API是Web API的一种实现方式，它遵循REST原则来设计接口。
• 不是所有的Web API都是RESTful的，但它们都遵循HTTP协议进行通信。

29. WebSocket

WebSocket是一种在单个TCP连接上进行全双工通讯的协议。它使得客户端和服务器之间的数据交换变得更加简单，允许服务器主动向客户端推送数据。WebSocket在需要高实时性、低延迟的Web应用中非常有用，如在线游戏、实时聊天应用、实时数据可视化等。

WebSocket的特点：

1. 全双工通信：客户端和服务器之间可以同时发送和接收数据，而不需要像HTTP那样，每次请求都需要等待响应。

2. 持久连接：WebSocket建立连接后，除非明确关闭，否则连接将一直保持打开状态，减少了频繁建立连接的开销。

3. 较少的控制开销：在连接建立后，WebSocket服务器和客户端之间交换数据时，只需要携带少量的数据头信息，从而减少了控制开销。

4. 支持二进制消息：WebSocket支持发送二进制数据，而不仅仅是文本数据，这使得它非常适合传输图片、音频、视频等多媒体内容。

30. 浏览器存储机制

浏览器提供了多种存储机制，以便在客户端持久化数据。这些存储机制包括：

1. Cookie：最初用于在客户端存储用户会话信息，但由于大小限制和安全性问题，现在更多用于存储简单的标识符（如会话ID）。

2. LocalStorage：允许你在用户的浏览器中存储数据，没有过期时间，直到被显式删除。它存储的数据会保存在浏览器的本地，即使用户关闭了浏览器窗口，数据仍然保留。

3. SessionStorage：与LocalStorage类似，但它存储的数据在页面会话期间可用，当页面会话结束时（如关闭浏览器标签页或窗口），数据将被清除。

4. IndexedDB：一个低级的API，用于客户端存储大量结构化数据。它提供了事务支持、索引、查询等高级功能，但使用起来相对复杂。

5. WebSQL（已废弃）：曾经被提出作为Web数据库的规范，但由于安全性和兼容性等问题，并未被广泛采纳和支持，现已被废弃。

6. Cache API：用于控制和管理HTTP请求的缓存。它提供了一种方式来存储和检索请求/响应对，以便在后续请求中快速访问。

这些存储机制各有优缺点，开发者可以根据应用的需求和场景选择合适的存储方式。

最后