面试

浏览器在加载页面时，大量的性能瓶颈集中在资源的请求、传输、解析与执行上。因此，网络层的性能优化主要目标是：减少请求次数、降低资源大小、缩短首屏时间、提升加载体验。 一、请求数量优化 1. 合理拆分和合并资源 按需加载（lazy loading / dynamic import）：不一次加载所有模块，只加载当前页面/功能所需资源。 资源合并（资源打包）：减少请求数量，如合并多个 CSS/JS 文件（现代工具也支持 HTTP2 下保留拆分）。 服务端渲染/预渲染：减轻首屏资源请求压力。 2. 使用缓存避免重复请求 使用浏览器缓存控制（Cache-Control、ETag、Last-Modified）； 对于不变资源，设置强缓存（immutable）； 对接口返回数据做缓存（前端缓存策略或 HTTP 层缓存）； 本地缓存，如 IndexedDB / LocalStorage 存储接口数据。 二、资源体积优化 1. 压缩与代码优化 启用 Gzip / Brotli 压缩静态资源（HTML、CSS、JS）； 压缩图像（WebP、AVIF）、字体、视频等媒体资源； 减少 polyfill 体积（如使用 core-js 按需引入）； 移除无用代码（Tree Shaking、CSS Purge、babel-plugin-transform-remove-console）； 2. 精简传输内容 请求接口时使用精简字段、分页、后端裁剪； GraphQL 可按需返回字段，减少冗余数据传输； 降低 Cookie 和请求头大小，避免请求体负担。 三、加载顺序与优先级优化 1. 关键资源优先加载 使用 preload、prefetch、dns-prefetch 等 <link> 标签提示浏览器提前加载； 使用 Webpack 的资源预加载配置控制打包 chunk 优先级； 首屏资源内联（inline critical CSS）避免阻塞渲染。 2. 非关键资源延后加载 图片懒加载（loading="lazy"、IntersectionObserver）； JS 异步加载（<script async|defer>）； 第三方 SDK、监控等可延迟初始化。 四、协议与传输层优化 1. 使用 HTTP/2 或 HTTP/3 多路复用，减少 TCP 连接数，提高并发请求效率； 头部压缩与服务器推送（HTTP/2 Push）； HTTP/3 基于 QUIC，有更快的连接建立速度与更少的丢包重传。 2. 减少不必要的重定向 避免链式跳转； 减少使用 302/301 等中间状态跳转，优化首次加载路径。 五、安全策略与跨域优化 合理设置 CORS，减少 preflight 请求； 使用同源策略时避免冗余 OPTIONS 请求； 减少跨域请求带来的额外开销（如 DNS、TLS 握手等）。 六、CDN 与资源分发优化 使用 CDN 加速静态资源访问，减少物理距离造成的 RTT； 使用全局 CDN 覆盖，支持边缘缓存与智能调度； 配合版本号和 Hash 控制缓存刷新策略。 七、服务端协同优化 接口合并：多个小请求可由后端合并为一次大请求返回； 接口压缩与限流：避免无用数据占带宽； 优化接口响应结构与字段粒度； 为前端提供异步批量资源接口（如配置/字典项/用户信息等合并加载）； 八、实际指标与监控优化点 首字节时间（TTFB）优化； 首屏渲染时间（FCP、LCP）优化； 页面总加载时间（Fully Loaded）优化； 网络错误率（如资源 404、接口失败率）监控； 使用 Performance API、Web Vitals、Lighthouse 工具分析网络瓶颈。 要点总结 网络优化的本质是：更快、更少、更智能地请求资源； 从请求数量、资源大小、传输协议、加载优先级、缓存策略、CDN 分发等多个维度同时入手； 优化不是单一操作，而是持续评估、定位瓶颈、迭代调整的过程； 实际开发中建议结合 Chrome DevTools、Lighthouse、Performance API 等工具进行精细化分析与验证。 常见考点 前端“网络层面的性能优化”是高频面试考点，涵盖了从资源加载、缓存、连接管理，到协议选择等多个方向。面试时往往从“用户输入 URL 到页面加载”这条链路入手，考查在网络传输环节提升页面性能的能力。 ...

写在前面：为什么要学习react-router底层源码? 为什么要弄明白整个路由流程？ 学习react-router，有助于我们学习单页面应用(spa)路由跳转原理，让我们理解从history.push，到组件页面切换的全套流程，使我们在面试的时候不再为路由相关的问题发怵，废话不说，让我们开启深入react-router源码之旅吧。 一 正确理解react-router 1 理解单页面应用 什么是单页面应用？ 个人理解，单页面应用是使用一个html下，一次性加载js, css等资源，所有页面都在一个容器页面下，页面切换实质是组件的切换。 2 react-router初探，揭露路由原理面纱 ①react-router-dom和react-router和history库三者什么关系 **history** 可以理解为react-router的核心，也是整个路由原理的核心，里面集成了popState,history.pushState等底层路由实现的原理方法，接下来我们会一一解释。 **react-router**可以理解为是**react-router-dom**的核心，里面封装了Router，Route，Switch等核心组件,实现了从路由的改变到组件的更新的核心功能,在我们的项目中只要一次性引入react-router-dom就可以了。 **react-router-dom**,在react-router的核心基础上，添加了用于跳转的Link组件，和histoy模式下的BrowserRouter和hash模式下的HashRouter组件等。所谓**BrowserRouter和HashRouter，也只不过用了history库中createBrowserHistory和createHashHistory方法** react-router-dom 我们不多说了，这里我们重点看一下react-router。 ②来个小demo尝尝鲜? import { BrowserRouter as Router, Switch, Route, Redirect,Link } from 'react-router-dom' import Detail from '../src/page/detail' import List from '../src/page/list' import Index from '../src/page/home/index' const menusList = [ { name: '首页', path: '/index' }, { name: '列表', path: '/list' }, { name: '详情', path: '/detail' }, ] const index = () => { return <div > <div > <Router > <div>{ /* link 路由跳转 */ menusList.map(router=><Link key={router.path} to={ router.path } > <span className="routerLink" >{router.name}</span> </Link>) }</div> <Switch> <Route path={'/index'} component={Index} ></Route> <Route path={'/list'} component={List} ></Route> <Route path={'/detail'} component={Detail} ></Route> {/* 路由不匹配，重定向到/index */} <Redirect from='/*' to='/index' /> </Switch> </Router> </div> </div> } 效果如下 ...

HTML5 中的拖拽（Drag and Drop，简称 DnD）功能为网页元素提供了原生的拖放支持。通过 HTML5 的拖放 API，开发者可以让元素变得可拖动，并实现拖拽和释放的交互效果。 HTML5 拖拽的基本原理 HTML5 拖拽操作的核心是 dragstart、dragover 和 drop 等事件。以下是拖拽的工作流程： 可拖动元素：使用 draggable="true" 使一个元素可被拖拽。 源元素触发拖拽：当用户点击并开始拖动可拖动元素时，触发 dragstart 事件。 拖拽中：拖拽过程中，目标区域会触发 dragover 事件。 释放元素：当用户释放被拖动的元素到目标区域时，目标会触发 drop 事件。 实现步骤 设置拖拽元素：使用 draggable="true" 使 HTML 元素可拖动。 监听拖拽事件： dragstart：当拖拽开始时触发。 dragover：在拖拽过程中，拖动到可放置目标区域时持续触发。 drop：当拖动的元素被释放到目标区域时触发。 阻止默认行为：dragover 和 drop 事件默认情况下是禁止的，需要使用 event.preventDefault() 来阻止默认行为，从而允许放置元素。 拖拽的相关事件 dragstart：在拖动开始时触发，用来设置拖动数据（如拖动的数据类型和数据内容）。 dragend：拖动操作结束时触发，可以用来清理状态。 dragenter：当拖动的元素进入目标区域时触发。 dragover：当拖动元素在目标区域上方移动时持续触发，默认情况下不会触发 drop，因此需要通过 event.preventDefault() 来允许放置。 dragleave：当拖动的元素离开目标区域时触发。 drop：当拖动的元素释放到目标区域时触发，可以获取拖动的数据。 拖拽实例 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>HTML5 拖拽示例</title> <style> #dragElement { width: 100px; height: 100px; background-color: lightcoral; text-align: center; line-height: 100px; cursor: grab; } #dropZone { width: 200px; height: 200px; background-color: lightblue; margin-top: 20px; text-align: center; line-height: 200px; } </style> </head> <body> <div id="dragElement" draggable="true">拖拽我</div> <div id="dropZone">放置到这里</div> <script> // 获取元素 const dragElement = document.getElementById('dragElement'); const dropZone = document.getElementById('dropZone'); // 拖拽开始事件 dragElement.addEventListener('dragstart', function(event) { // 设置数据，类型和内容 event.dataTransfer.setData('text', event.target.id); }); // 拖拽过程中在目标上方移动时，必须阻止默认行为 dropZone.addEventListener('dragover', function(event) { event.preventDefault(); }); // 放置事件 dropZone.addEventListener('drop', function(event) { event.preventDefault(); // 阻止默认行为 const data = event.dataTransfer.getData('text'); const draggedElement = document.getElementById(data); event.target.appendChild(draggedElement); // 将拖动的元素放入目标区域 }); </script> </body> </html> 代码说明 拖拽元素：draggable="true" 使得 #dragElement 可拖动。 拖拽开始：dragstart 事件设置了拖拽的元素数据，存入 dataTransfer 对象中。 允许放置：dragover 事件通过 event.preventDefault() 允许拖拽元素放置在目标区域。 放置元素：drop 事件在目标区域中，通过 event.dataTransfer.getData() 获取拖动的数据并进行处理。 常见考点 1. 基本概念与原理 定义：HTML5 提供了内置的拖拽功能，通过 draggable 属性和 Drag and Drop API 实现元素拖放操作。 原理：拖拽功能依赖一系列事件，如 dragstart、drag、dragend、dragover、drop 等来实现拖放操作。 2. 如何启用拖拽 draggable 属性：默认情况下，HTML 元素是不可拖拽的。要启用拖拽，需要设置元素的 draggable="true"。 <div draggable="true">Drag me!</div> 事件绑定：考察点可能包括如何通过 dragstart 等事件处理拖拽行为。 const draggableElement = document.getElementById('draggable'); draggableElement.addEventListener('dragstart', (event) => { event.dataTransfer.setData('text/plain', 'This is a draggable element'); }); 3. Drag and Drop 的核心事件 dragstart：用户开始拖动时触发，通常用于设置拖拽的数据和外观。 drag：在拖动过程中持续触发，可用于动态更新拖拽效果。 dragend：拖动结束时触发，可以用于清除拖拽状态。 dragenter：被拖拽的元素进入可放置区域时触发。 dragover：在拖动元素悬停在放置区域时持续触发，通常需要调用 event.preventDefault() 来允许放置。 dragleave：当拖动元素离开放置区域时触发。 drop：用户放开被拖动的元素时触发，用于处理放置操作。 4. 数据传输 dataTransfer 对象：event.dataTransfer 是拖拽过程中传输数据的关键对象。常见考点包括如何通过 dataTransfer.setData() 和 dataTransfer.getData() 方法在 dragstart 和 drop 事件之间传递数据。 // dragstart 中设置数据 event.dataTransfer.setData('text', 'Dragged Data'); // drop 中获取数据 const data = event.dataTransfer.getData('text'); 传输多种数据类型：考察如何传输不同的数据类型（如文本、URL、文件等）以及如何处理这些数据。 5. dropzone 区域的设置 允许放置元素：默认情况下，放置区域不会接受被拖拽的元素，需要在 dragover 事件中调用 event.preventDefault() 来显式地允许放置操作。 const dropzone = document.getElementById('dropzone'); dropzone.addEventListener('dragover', (event) => { event.preventDefault(); // 允许放置 }); 6. 拖拽的样式处理 自定义拖拽效果：通过 event.dataTransfer.setDragImage() 设置自定义的拖拽图片，考察点可能包括如何替换默认的拖拽预览图。 event.dataTransfer.setDragImage(imageElement, offsetX, offsetY); 拖拽时的 CSS 样式：考察如何使用 CSS 类和事件配合，实现拖拽时的视觉效果。 .dragging { opacity: 0.5; } 7. 跨页面或跨应用的拖拽 跨文档拖拽：考察是否了解如何处理跨 iframe 或浏览器窗口的拖拽。 拖拽文件：用户可以将外部文件（如从桌面拖动文件）拖入浏览器的 dropzone，需要处理 dataTransfer.files 属性。 const files = event.dataTransfer.files; 8. 拖拽与输入法的冲突 在移动设备上，拖拽和触摸事件可能存在冲突，因此考察点可能包括如何处理拖拽在移动端的实现或替代方案。 9. 可访问性 键盘可用性：默认拖拽操作主要依赖鼠标，因此考察点可能包括如何使拖拽操作可通过键盘导航，确保网站的无障碍性。 ARIA 支持：在实现拖拽功能时，如何使用 ARIA 属性为屏幕阅读器用户提供反馈是常见的可访问性考察点。 10. 兼容性 浏览器兼容性：HTML5 拖拽在不同浏览器中的支持情况不一致，尤其是在移动端，考察点可能包括如何处理浏览器兼容性问题，特别是在触摸设备上使用拖拽功能时的挑战。 11. 常见的应用场景 文件上传：通过拖拽文件进行上传是常见的考察场景，如何实现文件的拖放上传功能是常见问题。 可拖拽列表：如何通过拖拽重新排序列表项，如实现类似于 Trello 的拖放功能。 游戏和图形界面：拖放在交互式游戏或图形应用中被广泛使用，可能会考察如何通过拖拽元素实现复杂的交互效果。 12. 事件顺序 了解拖拽过程中的事件触发顺序也是一个重要的考察点，常见顺序为：dragstart -> drag -> dragenter -> dragover -> drop -> dragend。 13. 拖拽的取消 取消拖拽：通过调用 event.preventDefault() 可以阻止某些拖拽事件的默认行为，如取消 drop 事件。 14. 使用 JavaScript 框架实现拖拽 有些前端面试可能会考察如何利用 JavaScript 框架（如 React、Vue、Angular）实现拖拽交互，以及如何处理拖拽相关的状态管理和数据绑定。

引言 响应式布局指的是同一页面在不同屏幕尺寸下有不同的布局。传统的开发方式是PC端开发一套，手机端再开发一套，而使用响应式布局只要开发一套就够，缺点就是CSS比较重。下面是博客网站对不同设备适配后的结果，分别是iPhone5/SE,iphone6/7/8,iphone 6/7/8 plus,ipad pro,dell台式宽屏(1440 X 900)。 响应式设计与自适应设计的区别：响应式开发一套界面，通过检测视口分辨率，针对不同客户端在客户端做代码处理，来展现不同的布局和内容；自适应需要开发多套界面，通过检测视口分辨率，来判断当前访问的设备是pc端、平板、手机，从而请求服务层，返回不同的页面。 响应式布局的实现方案 1. 媒体查询 CSS3媒体查询可以让我们针对不同的媒体类型定义不同的样式，当重置浏览器窗口大小的过程中，页面也会根据浏览器的宽度和高度重新渲染页面。 如何选择屏幕大小分割点 如何确定媒体查询的分割点也是一个开发中会遇到的问题，下面是市场上的移动设备和电脑屏幕分辨率的分布情况，可以发现不同品牌和型号的设备屏幕分辨率一般都不一样 如果我们选择600px,900px,1200px,1800px作为分割点，可以适配到常见的14个机型： 当然这只是其中的一种分割方案，我们还可以这样划分：480px,800px,1400px,1400px 而作为曾经典型的响应式布局框架，Bootstrap是怎么进行断点的呢？ 上面的分割方案不一定满足项目中的实际需求，我们可以先用跨度大的分割点进行分割，如果出现不适配的情况可以再根据实际情况增加新的分割点。 移动优先 OR PC优先 不管是移动优先还是PC优先，都是依据当随着屏幕宽度增大或减小的时候，后面的样式会覆盖前面的样式。因此，移动端优先首先使用的是min-width，PC端优先使用的max-width。 移动优先: /* iphone6 7 8 */ body { background-color: yellow; } /* iphone 5 */ @media screen and (max-width: 320px) { body { background-color: red; } } /* iphoneX */ @media screen and (min-width: 375px) and (-webkit-device-pixel-ratio: 3) { body { background-color: #0FF000; } } /* iphone6 7 8 plus */ @media screen and (min-width: 414px) { body { background-color: blue; } } /* ipad */ @media screen and (min-width: 768px) { body { background-color: green; } } /* ipad pro */ @media screen and (min-width: 1024px) { body { background-color: #FF00FF; } } /* pc */ @media screen and (min-width: 1100px) { body { background-color: black; } } PC优先： ...

从后端路由开始 路由这个概念最先是后端出现的。在以前用模板引擎开发页面时，经常会看到这样 http://www.xxx.com/login 大致流程可以看成这样： 浏览器发出请求 服务器监听到80端口（或443）有请求过来，并解析url路径 根据服务器的路由配置，返回相应信息（可以是 html 字串，也可以是 json 数据，图片等） 浏览器根据数据包的 Content-Type 来决定如何解析数据 简单来说路由就是用来跟后端服务器进行交互的一种方式，通过不同的路径，来请求不同的资源，请求不同的页面是路由的其中一种功能。 前端路由 1. hash 模式 随着 ajax 的流行，异步数据请求交互运行在不刷新浏览器的情况下进行。而异步交互体验的更高级版本就是 SPA —— 单页应用。单页应用不仅仅是在页面交互是无刷新的，连页面跳转都是无刷新的，为了实现单页应用，所以就有了前端路由。 类似于服务端路由，前端路由实现起来其实也很简单，就是匹配不同的 url 路径，进行解析，然后动态的渲染出区域 html 内容。但是这样存在一个问题，就是 url 每次变化的时候，都会造成页面的刷新。那解决问题的思路便是在改变 url 的情况下，保证页面的不刷新。在 2014 年之前，大家是通过 hash 来实现路由，url hash 就是类似于： http://www.xxx.com/#/login 这种 #。后面 hash 值的变化，并不会导致浏览器向服务器发出请求，浏览器不发出请求，也就不会刷新页面。另外每次 hash 值的变化，还会触发hashchange 这个事件，通过这个事件我们就可以知道 hash 值发生了哪些变化。然后我们便可以监听hashchange来实现更新页面部分内容的操作： function matchAndUpdate () { // todo 匹配 hash 做 dom 更新操作 } window.addEventListener('hashchange', matchAndUpdate) 2. history 模式 14年后，因为HTML5标准发布。多了两个 API，pushState 和 replaceState，通过这两个 API 可以改变 url 地址且不会发送请求。同时还有popstate 事件。通过这些就能用另一种方式来实现前端路由了，但原理都是跟 hash 实现相同的。用了 HTML5 的实现，单页路由的 url 就不会多出一个#，变得更加美观。但因为没有 # 号，所以当用户刷新页面之类的操作时，浏览器还是会给服务器发送请求。为了避免出现这种情况，所以这个实现需要服务器的支持，需要把所有路由都重定向到根页面。 ...

DOM事件流（event flow ）存在三个阶段：事件捕获阶段、处于目标阶段、事件冒泡阶段。 Dom标准事件流的触发的先后顺序为：先捕获再冒泡。即当触发dom事件时，会先进行事件捕获，捕获到事件源之后通过事件传播进行事件冒泡。 addEventListener的第三个参数 在我们平常用的addEventListener方法中，一般只会用到两个参数，一个是需要绑定的事件，另一个是触发事件后要执行的函数，然而addEventListener还可以传入第三个参数： element.addEventListener(event, function, useCapture); 第三个参数默认值是false，表示在事件冒泡阶段调用事件处理函数;如果参数为true，则表示在事件捕获阶段调用处理函数。如果不写第三个参数则默认在事件冒泡阶段调用事件处理函数。 下面先介绍事件冒泡： 1. 事件冒泡 事件冒泡（dubbed bubbling）：当一个元素接收到事件的时候，会把他接收到的事件传给自己的父级，一直到 window （注意这里传递的仅仅是事件，例如click、focus等等这些事件， 并不传递所绑定的事件函数。） 事件源 =>根节点（由内到外）进行事件传播。 举例说明： 给三个盒子依次绑定点击事件，当点击盒子的时候，会依次触发父级元素的点击事件。 click small box click center box click big box 如果父元素没有绑定点击事件则只会触发点击盒子的事件。 click small box 如果子元素（small）的点击事件去掉，当我们点击small的时候会把当前操作的点击事件传递给父元素（因为父元素绑定了点击函数） click small box 有些时候我们不希望产生事件冒泡，所以可以 在子事件中加入e.stopPropagation() 取消冒泡 click small box 2. 事件捕获 事件捕获（event capturing）： 当鼠标点击或者触发dom事件时（被触发dom事件的这个元素被叫作事件源），浏览器会从根节点 =>事件源（由外到内）进行事件传播。 事件捕获与事件冒泡是比较类似的，最大的不同在于事件传播的方向。 还是举上面的例子： click small box 3. 事件委托 事件委托也称为事件代理。就是利用事件冒泡，把子元素的事件都绑定到父元素上。如果子元素阻止了事件冒泡，那么委托就无法实现。 原理实现： 不是每个子节点单独设置事件监听器，而是事件监听器设置在其父节点上，然后利用冒泡原理影响设置每个子节点。 应用场景：1000个button需要注册点击事件 如果循环给每个按钮添加点击事件，那么会增加内存损耗，影响性能 此时可以给button的父元素添加点击事件 这时相当于每个按钮都绑定了点击事件 优点： 替代循环绑定事件的操作，减少内存消耗，提高性能。比如： 在table上代理所有td的click事件。 在ul上代理所有li的click事件。 简化了dom节点更新时，相应事件的更新。比如： 不用在新添加的li上绑定click事件。 当删除某个li时，不用移解绑上面的click事件。 缺点： ...

编译器架构：LLVM 与 Clang iOS 开发中的两种主要语言 Objective-C 和 Swift 都基于 LLVM 编译器基础设施。理解 LLVM 的架构是理解 iOS 编译原理的基础。 LLVM 的三段式架构 LLVM 采用经典的前端-中间表示-后端三段式设计，将编译过程解耦为三个独立的阶段： flowchart LR subgraph Frontend["前端（Frontend）"] direction TB A1["Clang（OC/C/C++）"] A2["Swift 前端"] end subgraph Middle["中间表示"] direction TB B1["LLVM IR"] end subgraph Backend["后端（Backend）"] direction TB C1["arm64（iOS真机）"] C2["x86_64（模拟器）"] end A1 --> B1 A2 --> B1 B1 --> C1 B1 --> C2 阶段 职责 iOS 中的实现 前端（Frontend） 词法分析、语法分析、语义分析，将源码转换为中间表示 Clang（OC/C/C++）、Swift 前端 中间表示（IR） 与语言无关、与平台无关的中间形式，承载优化 LLVM IR（Swift 还有额外的 SIL 层） 后端（Backend） 将 IR 转换为目标平台的机器码 arm64（真机）、x86_64（Intel 模拟器） 三段式架构的核心优势是解耦：新增一门语言只需实现一个前端，新增一个目标平台只需实现一个后端，所有语言和平台共享同一套优化基础设施。这正是 Apple 能同时支持 OC 和 Swift 两种语言、多种架构（arm64、x86_64）的技术基础。 ...

一、梳理主干流程 知识体系中，最重要的是骨架，脉络。有了骨架后，才方便填充细节。所以，先梳理下主干流程： 浏览器接收url并开启一个新进程（这一部分可以展开浏览器的进程与线程的关系） 浏览器解析输入的 URL，提取出其中的协议、域名和路径等信息。（这部分涉及URL组成部分） 浏览器向 DNS 服务器发送请求，DNS服务器通过 多层查询 将该 域名 解析为对应的 IP地址 ，然后将请求发送到该IP地址上，与 服务器 建立连接和交换数据。（这部分涉及DNS查询） 浏览器与服务器建立 TCP 连接。（这部分涉及TCP三次握手/四次挥手/5层网络协议） 浏览器向服务器发送 HTTP 请求，包含请求头和请求体。（4,5,6,7包含http头部、响应码、报文结构、cookie等知识） 服务器接收并处理请求，并返回响应数据，包含状态码、响应头和响应体。 浏览器接收到响应数据，解析响应头和响应体，并根据状态码判断是否成功。 如果响应成功，浏览器接收到http数据包后的解析流程（这部分涉及到html - 词法分析，解析成DOM树，解析CSS生成CSSOM树（样式树），合并生成render渲染树（样式计算）。然后layout布局，分层，调用GPU绘制等，最后将绘制的结果合成最终的页面图像，显示在屏幕上。这个过程会发生回流和重绘）。 连接结束 -> 断开TCP连接 四次挥手 梳理出主干骨架，然后就需要往骨架上填充细节内容。 接下来重点介绍“浏览器渲染过程中的网络层面”。 二、浏览器接收url并开启一个新进程 这部分内容开始之前我们需要先通过一张图对 进程 和 线程 的关系有一个初步的了解。 1. 浏览器是多进程的 浏览器是多进程的，有一个主进程，每打开一个tab页面都会新开一个进程（某些情况下多个tab会合并进程）。 注意：在这里浏览器应该也有自己的优化机制，有时候打开多个tab页后，比如打开多个空白标签页。可以在Chrome任务管理器中看到，进程被合并了。 进程可能包括主进程，插件进程，GPU，tab页（浏览器内核）等等。 Browser进程：浏览器的主进程（负责协调、主控），只有一个。 第三方插件进程：每种类型的插件对应一个进程，仅当使用该插件时才创建。 GPU进程：最多一个，用于3D绘制等。 浏览器渲染进程（浏览器内核）（内部是多线程的）：默认每个Tab页面一个进程，互不影响。作用是页面渲染，脚本执行，事件处理等。（浏览器有时候会优化，如多个空白页合并成一个进程） 强化记忆：在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程） 下图以 chrome浏览器 为例。我们可以自己通过Chrome的更多工具 =》 任务管理器 自行验证查看，可以看到chrome的任务管理器中有多个进程（分别是每一个Tab页面有一个独立的进程，以及一个主进程） 然后能看到每个进程的内存资源信息以及cpu占有率。 2. 浏览器内核是多线程的 每一个tab页面可以看作是浏览器内核的一个进程，然后这个进程是多线程的，它有几大类子线程 GUI渲染线程：负责渲染浏览器界面，解析HTML，CSS，构建DOM树和RenderObject树，布局和绘制等。GUI渲染线程与JS引擎线程是互斥的。 JS引擎线程：也叫 JS 内核，负责解析执行 JS 脚本程序的主线程，例如 V8 引擎。JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（renderer进程）中无论什么时候都只有一个JS线程在运行JS程序。 事件触发线程：属于浏览器内核线程，主要用于控制事件，例如鼠标、键盘等，当事件被触发时，就会把事件的处理函数推进事件队列，等待 JS 引擎线程执行。 定时器触发线程：主要控制 setInterval和 setTimeout，用来计时，计时完毕后，则把定时器的处理函数推进事件队列中，等待 JS 引擎线程。 异步http请求线程：通过XMLHttpRequest连接后，通过浏览器新开的一个线程，监控readyState状态变更时，如果设置了该状态的回调函数，则将该状态的处理函数推进事件队列中，等待JS引擎线程执行。 ...

前言 文本分为两大部分讲解，一部分是首次挂载渲染原理，另一部分是更新和卸载原理，很多地方非常抽象，希望大家仔细阅读，不然容易脱节。废话不多话，开车！！ 正文 在开始之前，需要一些前置知识才能帮助我们更好的理解整个渲染过程。首先就是生命周期(16版本之后)，为什么要讲一下生命周期？跟渲染原理有关系吗？当然有，如果你不理解渲染原理的话，更新一个嵌套很深的组件你甚至连父与子生命周期执行的先后顺序都不知道。本文直接对照16版本之后的新生命周期进行讲解，就不讲解老版本了。 初探-生命周期 顾名思义，跟人生一样，生命周期就是一个组件从诞生到销毁的过程。React在组件的生命周期中注册了一系列的钩子函数，支持开发者在其中注入代码，并在适当的时机运行。这里指的生命周期仅针对于类组件中的钩子函数。因为生命周期不是本文的重点，所以Hooks中的新增的钩子函数在本文中均不涉及，可以以后出个Hooks原理篇。 从图中可以看到，我把生命周期分为了挂载阶段、更新阶段、卸载阶段三个阶段。同时，在挂载阶段和更新阶段都会运行getDerivedStateFromProps和render，卸载阶段很好理解，只有一个componentWillUnMount，在卸载组件之前做一些事情，通常用来清除定时器等副作用操作。那么挂载阶段和更新阶段中的生命周期我们来逐一看下每个运行点及作用。 1. constructor 在同一个类组件对象只会运行一次。所以经常来做一些初始化的操作。同一个组件对象被多次创建，它们的construcotr互不干扰。 注意：在construcotr中要尽量避免（最好禁止）使用setState。 我们都知道使用setState会造成页面的重新渲染，但是在初始化阶段，页面都还没有将真实DOM挂载到页面上，那么重新渲染的又有什么意义呢。除异步的情况，比如setInterval中使用setState是没问题的，因为在执行的时候页面早已渲染完成。但也最好不要，容易一些引起奇怪的问题。 constructor(props) { super(props); this.state = { num: 1 }; //不可以，直接Warning this.setState({ num: this.state.num + 1 }); //可以使用，但不建议 setInterval(()=>{ this.setState({ num: this.state.num + 1 }); }, 1000); } 2. 静态属性 static getDerivedStateFromProps 该方法是一个静态属性，在16版本之前不存在，在新版生命周期中主要用来取代componentWillMount和componentWillReceiveProps，因为这两个老生命周期方法在一些开发者不规范的使用下极容易产生一些反模式的bug。因为是静态方法，所以你在其中根本拿不到this，更不可能调用setState。 该方法在挂载阶段和更新阶段都会运行。它有两个参数props和state当前的属性值和状态。它的返回值会合并掉当前的状态（state）。 如果返回了非Object的值，那么它啥都不会做，如果返回的是Object，那么它将会跟当前的状态合并，可以理解为Object.assign。通常情况下，几乎不怎么使用该方法。 /** * 静态方法，首次挂载和更新渲染都会运行该方法 * @param {*} props 当前属性 * @param {*} state 当前状态 */ static getDerivedStateFromProps(props, state){ // return 1; //没用 return { num: 999, //合并到当前state对象 }; } 3. render 最重要的生命周期，没有之一。用来生成虚拟节点（vDom）树。该方法只要遇到需要重新渲染都会运行。同样的，在render中也严禁使用setState，因为会导致无限递归重新渲染导致爆栈。 ...

在 HTML 中，可以通过调用浏览器的全屏 API 实现页面或页面中的某个元素全屏显示。全屏 API 是 HTML5 提供的一项功能，允许将元素切换为全屏模式。 使用全屏 API 实现全屏 全屏 API 提供了以下常用方法和属性： requestFullscreen()：请求将元素设置为全屏模式。 exitFullscreen()：退出全屏模式。 fullscreenElement：返回当前正在全屏显示的 DOM 元素，如果没有元素全屏，则返回 null。 fullscreenchange 事件：当全屏状态发生变化时触发，用来监听进入或退出全屏。 实现全屏的基本步骤 选择你希望全屏的元素。 使用 element.requestFullscreen() 方法来进入全屏。 使用 document.exitFullscreen() 来退出全屏模式。 示例代码 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>全屏示例</title> <style> #fullscreenContent { width: 100px; height: 100px; background-color: lightblue; margin: 50px auto; text-align: center; line-height: 100px; } </style> </head> <body> <div id="fullscreenContent">点击全屏</div> <button id="exitFullscreenBtn" style="display:none;">退出全屏</button> <script> const fullscreenContent = document.getElementById('fullscreenContent'); const exitFullscreenBtn = document.getElementById('exitFullscreenBtn'); // 进入全屏模式 fullscreenContent.addEventListener('click', function() { if (fullscreenContent.requestFullscreen) { fullscreenContent.requestFullscreen(); } else if (fullscreenContent.mozRequestFullScreen) { // Firefox fullscreenContent.mozRequestFullScreen(); } else if (fullscreenContent.webkitRequestFullscreen) { // Chrome, Safari and Opera fullscreenContent.webkitRequestFullscreen(); } else if (fullscreenContent.msRequestFullscreen) { // IE/Edge fullscreenContent.msRequestFullscreen(); } exitFullscreenBtn.style.display = 'inline-block'; }); // 退出全屏模式 exitFullscreenBtn.addEventListener('click', function() { if (document.exitFullscreen) { document.exitFullscreen(); } else if (document.mozCancelFullScreen) { // Firefox document.mozCancelFullScreen(); } else if (document.webkitExitFullscreen) { // Chrome, Safari and Opera document.webkitExitFullscreen(); } else if (document.msExitFullscreen) { // IE/Edge document.msExitFullscreen(); } exitFullscreenBtn.style.display = 'none'; }); // 监听全屏状态变化 document.addEventListener('fullscreenchange', () => { console.log('全屏状态发生变化'); }); </script> </body> </html> 代码解释 进入全屏：点击 #fullscreenContent 的 div 时，调用 requestFullscreen() 方法使该元素进入全屏模式。 退出全屏：点击按钮 #exitFullscreenBtn，调用 document.exitFullscreen() 退出全屏模式。 跨浏览器兼容性：由于部分浏览器的全屏 API 有不同的实现方法，代码中兼容了各个主流浏览器的实现（例如 Chrome, Firefox, Safari, Edge）。 监听全屏状态变化：使用 fullscreenchange 事件来监听当前全屏模式的变化，可以在进入或退出全屏时执行额外操作。 全屏 API 的一些注意事项 全屏 API 只能在用户交互（如点击或按键事件）后触发，不能通过脚本自动进入全屏模式，这是为了防止用户体验被打断。 不同浏览器的全屏 API 实现可能稍有不同，因此通常需要做一些兼容性处理。 在移动端设备上，全屏模式的行为可能与桌面端有所不同。 总结 HTML5 的全屏 API 提供了一种简单而直观的方法来让页面或元素进入全屏模式。通过 requestFullscreen() 方法可以将任意元素全屏显示，exitFullscreen() 则用来退出全屏模式。结合 fullscreenchange 事件可以对全屏状态进行监控，实现更加丰富的交互体验。 ...