前端开发

响应式是指实现不同屏幕分辨率的终端上浏览网页的不同展示方式。 本知识点的主要内容有： 为什么要使用响应式图片 怎么实现响应式图片 1、为什么要使用响应式图片 假如有一张图片的显示宽度为200px，那么，它在 1x（即设备像素比为 1 的显示器） 的显示器上，是占了 200 个物理像素（即实际所占的像素）；它在 2x 的显示器上，实际上是占了 400 个物理像素；在 3x 的显示器上，实际上是占了 600 个物理像素；在 4x 的显示器上就是占了 800 个物理像素。 如果这个图片只提供 200 像素的尺寸，那么在 2x~4x 的显示器上看起来就很模糊。如果只提供 800 像素的版本，那么在 1x~3x 的设备上会显得多余，因为加载时间会相较长，所以我们要使用响应式图片。 再比如一个场景，相同的banner，在电脑上需要使用大图，但是手机上面使用小图，不然会造成手机上加载慢浪费流量等问题，这也可以使用响应式图片来解决。 2、实现方法 css3 media query 一个办法是使用backgound-image结合媒体查询，如下所示： .banner{ background-image: url(/static/large.jpg); } @media screen and (max-width: 767px){ background-image: url(/static/small.jpg); } 这种方法的缺点是对SEO不太友好，因为如果使用img标签还可以写个alt属性。 picture标签 <picture> <source srcset="banner_w1000.jpg" media="(min-width: 801px)"> <source srcset="banner_w800.jpg" media="(max-width: 800px)"> <img src="banner_w800.jpg" alt=""> </picture> 如上，如果页面宽度大于800px（PC），则加载大图，而在手机上加载小图。这样写浏览器就只会加载source里面的一张图片。但是如果是用js动态插进去的，它还是会去加载两张，只有写在html里面加载初始化页面的时候才只加载一张。 picture必须要写img标签，否则无法显示，对picture的操作最后都是在img上面，例如onload事件是在img标签触发的，picture和source是不会进行layout的，它们的宽和高都是0。 另外使用source，还可以对图片格式做一些兼容处理： <picture> <source type="image/webp" srcset="banner.webp"> <img src="banner.jpg" alt=""> </picture> webp在保持同等清晰度的情况下，体积可以减少一半，但是目前只有Chrome支持，Safari和firefox一直处于实验阶段，所以其它的浏览器如firefox将会加载jpg格式的照片： ...

传统应用发布模式 开发人员：在开发环境完成代码编写，单元测试，测试通过后提交到代码仓库 运维人员：把项目部署到测试环境，供QA团队测试，测试通过后，部署生成环境 测试人员：进行测试，测试完成后通知运维部署生产环境 缺点 项目在早期就存在错误，但到最后集成的时候才发现 需要手动操作，易错率高 开发与运维需要及时沟通 有了以上缺点，那么就有了CI/CD CI/CD 持续集成(CI): 合并开发人员正在编写的所有代码 一天内进行多次合并和提交代码 从存储库或生产环境中进行构建和自动化测试，确保没有集成问题并及早发现任何问题 持续交付(CD): 可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中 持续部署，并自动将更改推送到生产中 GitLab内置CI/CD 运行流水线任务 Job 在文件中可以定义一个或多个作业，每个作业具有唯一的名称，每个作业是独立执行的，每个作业至少包含一个script stages： 用于定义作业可以使用的阶段，并且是全局定义，同一个阶段的作业并行运行，不同阶段按顺序运行 only： 用分支策略来限制jobs构建 script: 项目中package中的脚本 environment： 定义此作业完成部署的环境名称 下面是每个jobs的详细变量名 Keyword Required Description script yes Runner执行的命令或脚本 image no 所使用的docker镜像，查阅使用docker镜像 services no 所使用的docker服务，查阅使用docker镜像 stage no 定义job stage（默认：test） type no stage的别名（已弃用） variables no 定义job级别的变量 only no 定义一列git分支，并为其创建job except no 定义一列git分支，不创建job tags no 定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags） allow_failure no 允许job失败。失败的job不影响commit状态 when no 定义何时开始job。可以是on_success，on_failure，always或者manual dependencies no 定义job依赖关系，这样他们就可以互相传递artifacts cache no 定义应在后续运行之间缓存的文件列表 before_script no 重写一组在作业前执行的命令 after_script no 重写一组在作业后执行的命令 environment no 定义此作业完成部署的环境名称 coverage no 定义给定作业的代码覆盖率设置 配置.gitlab-ci.yml stages: - deploy_dev - deploy_test - deploy_production deploy_dev: stage: deploy_dev environment: name: dev only: - dev script: - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH} - npm run build:dev - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=/opt/devroot/" deploy_test: stage: deploy_test environment: name: test only: - master script: - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH} - npm run build:stage - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=${WEB_ROOT_PATH}" deploy_production: stage: deploy_production only: - production when: manual script: - npm install - npm run build:prod - ansible-playbook ansible-deploy.yml --extra-vars "hosts=dvs-front-prod projectDir=${PROJECT_PATH} projectName=xianglin-cloud-ui/${PROJECT_NAME} webRootPath=/opt/" 上面这个.yml文件,我们首先定义了三个阶段，deploy_dev部署到dev环境，并且拉去的是dev分支代码; deploy_test部署到test环境，拉去的是master分支代码，deploy_production拉取production分支代码，执行完后需要手动操作 ...

一 前言 我们来一起探讨一下React事件原理，这篇文章，我尽量用通俗简洁的方式，把React事件系统讲的明明白白。 我们讲的react版本是16.13.1 , v17之后react对于事件系统会有相关的改版，文章后半部分会提及。 老规矩，在正式讲解react之前，我们先想想这几个问题(如果我是面试官，你会怎么回答?)： 我们写的事件是绑定在dom上么，如果不是绑定在哪里？ 为什么我们的事件不能绑定给组件？ 为什么我们的事件手动绑定this(不是箭头函数的情况) 为什么不能用 return false 来阻止事件的默认行为？ react怎么通过dom元素，找到与之对应的 fiber对象的？ onClick是在冒泡阶段绑定的？ 那么onClickCapture就是在事件捕获阶段绑定的吗？ 必要的知识概念 在弄清楚react事件之前，有几个概念我们必须弄清楚，因为只有弄明白这几个概念，在事件触发阶段，我们才能更好的理解react处理事件本质。 我们写在JSX事件终将变成什么？ 我们先写一段含有点击事件的react JSX语法，看一下它最终会变成什么样子？ class Index extends React.Component{ handerClick= (value) => console.log(value) render(){ return <div> <button onClick={ this.handerClick } > 按钮点击 </button> </div> } } 经过babel转换成React.createElement形式，如下： 最终转成fiber对象形式如下： fiber对象上的memoizedProps 和 pendingProps保存了我们的事件。 什么是合成事件？ 通过上一步我们看到了，我们声明事件保存的位置。但是事件有没有被真正的注册呢？我们接下来看一下： 我们看一下当前这个元素<button>上有没有绑定这个事件监听器呢？ button上绑定的事件 我们可以看到 ，button上绑定了两个事件，一个是document上的事件监听器，另外一个是button，但是事件处理函数handle，并不是我们的handerClick事件，而是noop。 noop是什么呢？我们接着来看。 原来noop就指向一个空函数。 然后我们看document绑定的事件 可以看到click事件被绑定在document上了。 接下来我们再搞搞事情😂😂😂，在demo项目中加上一个input输入框，并绑定一个onChange事件。睁大眼睛看看接下来会发生什么？ class Index extends React.Component{ componentDidMount(){ console.log(this) } handerClick= (value) => console.log(value) handerChange=(value) => console.log(value) render(){ return <div style={{ marginTop:'50px' }} > <button onClick={ this.handerClick } > 按钮点击 </button> <input placeholder="请输入内容" onChange={ this.handerChange } /> </div> } } 我们先看一下input dom元素上绑定的事件 ...

一句话总结：中间人攻击的关键在于获取公钥。 一、我和小美传纸条 我和隔壁班的小美互相喜欢，经常互相传纸条。但我懒得动，一般让老王帮我顺路带过去，我信任老王，所以就是简单把纸对折一下就交给老王了。 二、带锁的盒子 有一天我发现，老王居然偷看我的纸条！ 我很生气，于是买了一个带锁的盒子，并配了两把钥匙🔑，我留一把，另一把让老王交给小美。我心想这下子老王没钥匙，看不了我们的纸条了。 三、一个需要两把钥匙的盒子 又过了几天，我发现老王还是会偷看，为什么呢？原来这老小子当初传递钥匙的时候，自己去复刻了一把！ 于是我又想了一个办法，换了一个更高级的盒子，这个盒子必须用一对钥匙才能使用，使用公钥上锁，必须使用私钥才能打开。我委托老王把我的公钥交给小美，把小美的公钥拿给我。 以后我们都用对方的公钥来进行加密，对方用自己的私钥就能解密。而且就算老王把公钥拿去复刻一把也没关系，没有私钥他就打不开箱子，完美！ 四、班主任 过了几天，我发现老王还是能偷看我们的纸条，为什么呢？？？？？？ 我想了好几天终于想明白了！原来老王当初传递钥匙的时候，他把我俩的公钥自己留下了，这老小子把自己的公钥给了我们俩。他现在有手里有四把钥匙，想看什么看什么！ 这次我们终于意识到问题的关键，不管什么方案，让老王传钥匙就得坏事！于是我和小美商量好，这次不通过老王，而是通过我的班主任传递公钥，终于可以愉快的聊天了！ 五、网络中的加密知识 对称加密 对称加密使用同一个密钥进行加密和解密。它的优点是速度快，它的问题是密钥传播过程中一旦泄露，就功亏一篑了。 非对称加密 非对称加密使用一对密钥：公钥和私钥。公钥用于加密，私钥用于解密。它的优点是密钥分发问题得到解决，公钥可以公开传播。缺点是速度较慢，通常用于加密小数据量或密钥交换。常见做法是通过非对称加密建立链接，交换对称加密密钥，然后使用对称加密的方式进行消息传递。 证书 数字证书是由认证机构（CA）签发的，包含公钥及其持有者身份信息的电子文档。它通过 CA 的数字签名验证其真实性，确保通信双方的身份和公钥的可信性。（证书就是上面例子中的班主任，是一个可信任的获取对方公钥的机构。） 六、中间人攻击 中间人攻击的关键在于攻击者成功获取并提供可信公钥，欺骗用户使其认为其公钥是合法服务器的公钥。这可以通过伪造证书或利用受损的 CA 来实现。（用上面例子来说，就是老王把自己的公钥伪装成小美的公钥给了我） 作为普通用户防御措施很简单，当访问一个网站时，如果浏览器弹出“证书不可信”告警的时候，不要点“我信任”。 常见考点 1. 中间人攻击的基本概念 问题： 什么是中间人攻击？请用通俗的语言解释。 中间人攻击有哪些典型的攻击方式？ 被动攻击（如窃听）。 主动攻击（如数据篡改）。 中间人攻击的危害有哪些？ 关键点： 中间人攻击是一种攻击者拦截并篡改通信内容的攻击。 危害包括：窃取敏感数据（如密码）、篡改通信内容、伪装身份等。 2. 中间人攻击的原理 问题： 中间人攻击是如何实现的？请简要描述其工作流程。 在 HTTP 中，为什么容易发生中间人攻击？ HTTPS 是否完全能防止中间人攻击？为什么？ DNS 劫持和 ARP 欺骗是如何帮助实现中间人攻击的？ 关键点： 工作流程： 攻击者充当通信双方之间的“中间人”。 拦截通信数据，可能进行监听或篡改。 常见技术： ARP 欺骗：伪装网关。 DNS 劫持：将域名解析到攻击者控制的服务器。 Wi-Fi 劫持：在公共网络中拦截通信数据。 3. 防御中间人攻击的技术措施 问题： HTTPS 如何防御中间人攻击？它的安全机制是什么？ 什么是证书信任链？如何防止伪造的证书？ 什么是 HSTS（HTTP Strict Transport Security）？它如何防御中间人攻击？ 什么是双向 SSL/TLS？它如何进一步提高安全性？ 如何防止公共 Wi-Fi 中的中间人攻击？ 关键点： ...

1、普通流（常规流） 文档流（流式布局）分为 普通流、定位流、浮动流，不同流内的块级元素和行内元素的布局方式不同，布局方式用 FC（格式化上下文，含有 块级格式化上下文、内联格式化上下文、层叠格式化上下文、灵活格式化上下文等）来命名； 普通流中的布局规则默认为块级盒子从上到下，垂直排列；内联盒子从左到右，水平排列等；（书写模式（writing-mode）会对流布局产生影响； 2、position 属性有： static：默认值，元素依然按照 普通流 的定位规则定位； relative absolute sticky fixed 使用 position 会脱离常规流，成为定位流，并有其自己的定位规则； 3、float 属性有： left right none inherit 使用 float 会脱离常规流，成为浮动流，并有其自己的定位规则； 4、table 使用 HTML 标签来布局； <table> <tr> <th></th> <th></th> </tr> <tr> <td></td> <td></td> </tr> </table> 5、flex 2009 年 W3C 提供的方案，注意只有 IE 10+ 支持 flex； 重要的概念：flex 容器，flex 项目，主轴，交叉轴； 设置某个元素的属性 display: flex;，此元素就成了 flex 容器，flex 容器内的元素是 flex 项目； flex 容器的属性： flex-direction flex-wrap flex-flow justify-content align-items align-content flex 项目的属性 flex （flex-grow、flex-shrink、flex-basis） order align-self 6、grid 二维布局方式，相对于使用 HTML 结构实现的 table 布局，grid 布局都是在 CSS 中完成的； ...

一、插槽的几种使用方式 1. 普通插槽 举例来说，这里有一个 <FancyButton> 组件，可以像这样使用： <FancyButton> Click me! <!-- 插槽内容 --> </FancyButton> 而 <FancyButton> 的模板是这样的： <button class="fancy-btn"> <slot></slot> <!-- 插槽出口 --> </button> <slot> 元素是一个 插槽出口 (slot outlet)，标示了父元素提供的 插槽内容 (slot content) 将在哪里被渲染。 最终渲染出的 DOM 是这样： <button class="fancy-btn">Click me!</button> 2. 具名插槽 有时在一个组件中包含多个插槽出口是很有用的。举例来说，在一个 <BaseLayout> 组件中，有如下模板： <div class="container"> <header> <!-- 标题内容放这里 --> </header> <main> <!-- 主要内容放这里 --> </main> <footer> <!-- 底部内容放这里 --> </footer> </div> 对于这种场景， <slot> 元素可以有一个特殊的 attribute name，用来给各个插槽分配唯一的 ID，以确定每一处要渲染的内容： ...

聊聊 for of 说起 for of 相信每个写过 JavaScript 的人都用过 for of ，平时我们用它做什么呢？大多数情况应该就是遍历数组了，当然，更多时候，我们也会用 map() 或者 filer() 来遍历一个数组。 但是就像我们标题里面说的，它跟 Generator 能扯上什么关系呢？ 首先我们想一个问题，为什么使用 for of 或者 map()/filer() 方法就可以遍历一个数组 (或者类数组对象: Strings , Maps , Sets , arguments ) 呢？ 为什么不能用他们来遍历一个对象呢？ 你能学到什么 对 for of 更深入的理解 iterator 到底是何方神圣? 数组也是对象，为什么不能用 for of 来遍历对象呢？ 如何实现对象的 for of? Generator 又是何方神圣？他有什么用呢？ 类数组对象的玄机 在真正揭开谜底之前，站在 for of 的角度想一下，现在让你去遍历一个数组，你需要知道什么信息呢？ 对应下标的值 是否遍历结束的标志 带着这样的思考，我们打印一个数组来看看这里面的玄机： const numbersArray = [1, 2, 3]; console.dir(numbersArray); 数组 (或者类数组对象: Strings , Maps , Sets , arguments ) 的原型中都实现了一个方法 Symbol.iterator，问题来了，那么这个 Symbol.iterator 又有什么用呢？ 拿出来试一下就知道了： ...

纵观JavaScript中所有必须需要掌握的重点知识中，函数是我们在初学的时候最容易忽视的一个知识点。在学习的过程中，可能会有很多人、很多文章告诉你面向对象很重要，原型很重要，可是却很少有人告诉你，面向对象中所有的重点难点，几乎都与函数息息相关。 包括之前几篇文章介绍的执行上下文，变量对象，闭包，this等，都是围绕函数的细节来展开。 很多人在学习中，很急切的希望自己快一点开始学习面向对象，学习模块，学习流行框架，然后迅速成为高手。但是我可以很负责的告诉你，关于函数的这些基础东西没理解到一定程度，那么你的学习进展一定是举步维艰的。 所以，大家一定要重视函数！ 当然，关于函数的重点，难点在前面几篇文章都已经说得差不多了，这篇文章主要总结一下函数的基础知识，并初步学习函数式编程的思维。 一、函数声明、函数表达式、匿名函数与自执行函数 关于函数在实际开发中的应用，大体可以总结为函数声明、函数表达式、匿名函数、自执行函数。 函数声明 我们知道，JavaScript中，有两种声明方式，一个是使用var的变量声明，另一个是使用function的函数声明。 在前端基础进阶（三）：变量对象详解中我有提到过，变量对象的创建过程中，函数声明比变量声明具有更为优先的执行顺序，即我们常常提到的函数声明提前。因此我们在执行上下文中，无论在什么位置声明了函数，我们都可以在同一个执行上下文中直接使用该函数。 fn(); // function function fn() { console.log('function'); } 函数表达式 与函数声明不同，函数表达式使用了var进行声明，那么我们在确认他是否可以正确使用的时候就必须依照var的规则进行判断，即变量声明。我们知道使用var进行变量声明，其实是进行了两步操作。 // 变量声明 var a = 20; // 实际执行顺序 var a = undefined; // 变量声明，初始值undefined，变量提升，提升顺序次于function声明 a = 20; // 变量赋值，该操作不会提升 同样的道理，当我们使用变量声明的方式来声明函数时，就是我们常常说的函数表达式。函数表达的提升方式与变量声明一致。 fn(); // 报错 var fn = function() { console.log('function'); } 上例子的执行顺序为： var fn = undefined; // 变量声明提升 fn(); // 执行报错 fn = function() { // 赋值操作，此时将后边函数的引用赋值给fn console.log('function'); } 因此，由于声明方式的不同，导致了函数声明与函数表达式在使用上的一些差异需要我们注意，除此之外，这两种形式的函数在使用上并无不同。 关于上面例子中，函数表达式中的赋值操作，在其他一些地方也会被经常使用，我们清楚其中的关系即可。 在构造函数中添加方法 function Person(name) { this.name = name; this.age = age; // 在构造函数内部中添加方法 this.getAge = function() { return this.age; } this. } // 给原型添加方法 Person.prototype.getName = function() { return this.name; } // 在对象中添加方法 var a = { m: 20, getM: function() { return this.m; } } 匿名函数 ...

对于大多数前端工程师来说，音视频技术是一个比较少涉足的领域， 本知识点主要介绍流媒体技术中的文本、图形、图像、音频和视频多种理论知识，涉及到播放器、web媒体技术、主流框架等内容。 一、音视频基础 1.1 视频 1.1.1 基础概念 码率 单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件。 帧率 对视频来说，帧率对应这观看卡顿。帧率越高，流畅度越高，低帧率会造成视觉卡顿。 压缩率 经过压缩后文件的大小 / 原始文件的大小 * 100% = 压缩率。编码压缩越小越好，但压得越小，解压时间 分辨率 用于度量图像内数据量多少的一个参数，和视频清晰度息息相关。 1.1.2 视频容器格式 容器格式相信大家经常见到： MP4、AVI、FLV、TS/M3U8、WebM、OGV、MOV… 1.1.2 视频编码格式 H.264 目前最流行的编码格式。 H.265 新型的编码格式，高效的视频编码。用来以替代H.264/AVC编码标准。 VP9 VP9是WebM Project开发的下一代视频编码格式 。VP9支持从低比特率压缩到高质量超高清的所有Web和移动用例，并额外支持10/12位编码和HDR AV1 AOM（Alliance for Open Media，开放媒体联盟）制定的一个开源、免版权费的视频编码格式。AV1是google制定的VP9标准的继任者，也是H265强有力的竞争者。 1.2 音频 1.2.1 基础概念 采样率 音频采样率是指录音设备在一秒钟内对声音信号的采样次数，采样频率越高声音的还原就越真实越自然。 采样大小 一秒钟所采的样本数为比特率，每个样本中信息的比特数就是位深，即采样精度，单位为Bit。 比特率 指每秒传送的比特(bit)数，又称数据信号速率。单位为比特/秒、千比特/秒或兆比特/秒。比特率越高，表示单位时间传送的数据就越多。 压缩率 原始音频数据与通过PCM等压缩编码技术压缩后的数据大小的比率 1.2.2 音频容器格式 音频格式也比较常见：WAV、AIFF、AMR、MP3、Ogg… 1.2.3 音频编码格式 PCM 脉冲编码调制(Pulse Code Modulation,PCM)，PCM是数字通信的编码方式之一。 AAC-LC(MPEG AAC Low Complexity) 低复杂度编码解码器（AAC-LC — 低复杂度高级音频编码）是低比特率、优质音频 的高性能音频编码解码器。 AAC-LD （又名AAC低延迟或MPEG-4低延迟音频编码器），为电话会议和OTT服务量身打造的低延迟音频编解码器 LAC（Free Lossless Audio Codec） 免费无损音频编解码器。是一套著名的自由音频压缩编码，其特点是无损压缩。 2012年以来它已被很多软件及硬件音频产品（如CD等）所支持。 1.3 常见标签 1.3.1 <audio> 元素 1.3.1.1 基本用途 <audio> 元素用于在网页中嵌入音频内容。它可以播放音乐、播客、音效等。 ...

什么是 Bundle Splitting？ Bundle Splitting（代码分割）是一种将前端资源拆分成更小、独立的模块的技术。传统上，前端资源（如 JavaScript、CSS 和图片等）被打包成单个文件，通常称为“bundle”。这种方式存在一个问题，即无论用户需要哪些功能，都必须下载整个 bundle。而 Bundle Splitting 技术通过将代码拆分为更小的模块，按需加载，可以有效解决这个问题。 Bundle Splitting 的优点 减少初始加载时间 通过将代码拆分为多个小块，可以减少初始加载时间。当用户首次访问网页时，只需下载当前页面所需的资源，而无需等待整个应用程序的加载完成。这可以极大地提高页面的响应速度，并减少用户的等待时间。 提升用户体验 通过将代码分割成模块，可以使应用程序更具响应性。当用户与应用进行交互时，只需加载所需的代码块，而不是整个应用。这将减少不必要的资源消耗，并使用户感觉应用更加流畅和快速。 优化缓存策略 拆分代码还能优化缓存策略。当应用程序发生更改时，只需重新加载发生变化的模块，而不必重新下载整个应用。这减少了不必要的网络请求，提高了应用的更新效率，并减轻了服务器的负载。 并行加载资源 通过将代码拆分为多个模块，可以实现并行加载资源。浏览器能够同时下载多个文件，从而减少整体加载时间。这对于大型应用程序和复杂的前端框架特别有益，能够更好地利用浏览器的并行下载能力，提高资源的加载效率。 代码复用和维护 通过将代码分割成模块，可以更好地实现代码的复用和维护。不同的模块可以根据需求进行加载和升级，使得代码结构更加清晰、模块化。这也有助于团队合作，不同开发者可以并行工作在不同的模块上，提高开发效率和代码质量。 Bundle Splitting 的缺点 增加了网络请求 拆分代码会增加应用程序的网络请求次数。每个模块都需要进行一次独立的网络请求，这可能会导致一些额外的延迟和性能损失。在网络条件较差的情况下，这可能会对用户体验产生一定影响。 增加了开发复杂性 使用 Bundle Splitting 技术需要对应用程序的依赖关系进行深入分析和管理。开发人员需要仔细考虑代码的拆分点，以及如何在运行时动态加载模块。这增加了开发复杂性，并要求开发人员具备较高的技术水平和经验。 潜在的代码冗余 当模块之间存在共享的代码片段时，可能会出现潜在的代码冗余问题。如果不合理地进行代码拆分，可能会导致多个模块中存在相同的代码，增加了资源的下载和维护成本。因此，在进行代码拆分时，需要仔细考虑代码复用和代码冗余的问题。 需要额外的工具和配置 Bundle Splitting 需要使用额外的工具和配置来实现代码的拆分和动态加载。这可能需要对构建工具进行配置，如 Webpack、Rollup 等，以及对模块加载器进行调整。这增加了一些学习成本和开发成本，尤其是对于新手来说。 Bundle Splitting 的适用场景 Bundle Splitting 技术适用于大型的 Web 应用程序，特别是那些具有复杂功能和大量依赖的应用。以下是一些适合使用 Bundle Splitting 的场景： 大型单页应用：对于由多个模块组成的单页应用，使用 Bundle Splitting 可以提高初始加载速度，提升用户体验。 按需加载：对于需要动态加载不同功能模块的应用，Bundle Splitting 可以根据用户的需求按需加载模块，减少不必要的资源消耗。 公共库和框架：对于使用公共库或框架的应用，可以将这些库和框架拆分成单独的模块，以便在多个页面中共享和复用。 国际化支持：对于需要支持多种语言的应用，可以将不同语言的资源文件拆分成独立的模块，根据用户的语言偏好进行加载。 代码分支管理：对于大型团队开发的项目，使用 Bundle Splitting 可以更好地实现代码的分支管理和并行开发，提高开发效率。 Bundle Splitting 在知名项目中的应用 示例 1：React.lazy 和 Suspense React.js 是一个广泛使用的 JavaScript 库，用于构建用户界面。React 提供了 React.lazy 和 Suspense API 来实现 Bundle Splitting。 ...