2023高薪前端面试题（三、前端进阶——前端工程化）-优快云博客

本文链接：https://blog.youkuaiyun.com/iaz999/article/details/130643297

• Babel 的原理是什么?

参考回答：

babel的转译过程分为三个阶段，这三个步骤分别是：

1、解析parse:将代码解析生成抽象语法树（AST）,即词法分析和语法分析的过程。
2、转换Transform:对于AST进行变换的一些列的操作，babel接收得到的AST并通过babel-traverse对其进行遍历，在此过程中进行添加，更新以及移除等操作，返回结果为转换后的新AST。
3、生成Generate:将变换后的AST再转换为JS代码，使用到的模块是babel-generator。

如何编写一个babel插件

Babel的核心模块@babel/core,@babel/parser, @babel/traverse,@babel/generator提供了完整的编译流程。而具体的转换逻辑需要插件来完成。在使用Babel时，我们可以通过指定文件指定的plugin和preset。Babel 会递归读取 preset，最终获取一个大的 plugins 数组，用于后续使用。

常见的presets

@babel/preset-env
@babel/preset-typescript
@babel/preset-react
@babel/preset-flow

babel的原理_babel原理_卖菜的小白的博客-优快云博客

• webpack 用来干什么的

什么是WebPack?

WebPack可以看做是模块打包机：它做的事情是，分析项目结构，找到JavaScript模块以及其它的一些浏览器不能直接运行的拓展语言（Scss，TypeScript等），并将其转换和打包为合适的格式供浏览器使用。
webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。

主要承担功能：
打包：将多个文件打包成一个文件，减少服务器压力和下载带宽；
转换：将预编译语言转换成浏览器识别的语言；
优化：性能优化
webpack特点：

1.代码拆分

webpack 有两种组织模块的依赖方式：同步、异步。异步依赖将作为分割点，形成一个新的块；在优化了依赖树之后，每一个异步区块都将作为一个文件被打包。
2.智能解析
webpack 有一个智能解析器，几乎可以处理任何第三方库。无论它们的模块形式是 CommonJS、 AMD 还是普通的 JS 文件；甚至在加载依赖时，允许使用动态表达式 require("./templates/" + name + ".jade")
3. 快速运行
webpack
使用异步 I/O 、多级缓存提高运行效率，使得 webpack 以难以令人置信的速度快速增量编译。

Vite和Webpack区别

1.什么是Vite？

　　Vite是尤雨溪在开发vue3的时候开发的一个web开发构建工具。

　　极速的服务启动：使用原生 ESM 文件，无需打包！
　　轻量快速的热重载：无论应用程序大小如何，都始终极快的模块热重载（HMR)
　　丰富的功能：对 TypeScript、JSX、CSS 等支持开箱即用。

　　Vite使用简单，只需执行初始化命令，就可以可得到一个预设好的开发环境，开箱即可获得一堆功能，包括：css预处理、html预处理、异步加载、分包、压缩、HMR等。使用复杂度介于Paracel和Webpack的中间，只是暴露了极少数的配置项和plugin接口，既不会像Paracel一样配置不灵活，又不会像Webpack一样需要了解庞大的loader、plugin生态。灵活适中，复杂度适中

2.相比Webpack，Vite有什么优势？

　　a. vite开发服务器启动速度比webpack快。

　　　　webpack会先打包，然后启动开发服务器，请求服务器时直接给予打包结果

　　　　由于vite启动的时候不需要打包，也就不需要分析模块依赖，编译，使用原生ES模块导入方式，所以启动速度非常快；

　　　　vite采用的是按需动态编译的模式，当浏览器请求需要的模块时，再对模块进行编译，这种处理模式极大的缩短了编译时间，当项目越大，文件越多，vite的开发时优势越明显

　　b. vite的热更新比webpack快。vite在HRM方面（HMR是指当你对代码进行修改并保存后，webpack对代码重新打包，并将新的模块发送到浏览器端，浏览器通过替换旧的模块，在不刷新浏览器的前提下，就能够对应用进行更新），当改动了一个模块后，vite仅需让浏览器重新请求该模块即可，不像webpack那样需要把该模块的相关依赖模块全部编译一次，效率更高。

　　c.由于现代浏览器本身就支持ES Module，会自动向依赖的Module发出请求。vite充分利用了这点，将开发环境下的模块文件，就作为浏览器要执行的文件，而不是像webpack那样进行打包合并

　　d. vite 使用esbuild（Go编写）预构建依赖，比webpack的nodejs，快10-100倍　　

3.从Webpack方面能不能做一些编译构建方面的优化

　　a. 多入口的情况下，使用CommonsChunkPlugin来提取公共代码

　　b. 通过externals配置来提取常用库

　　c. 使用Happypack实现多线程加速编译

　　d. 使用Tree-shaking和Scope Hoisting来剔除多余代码

　　e. 使用 webpack-uglify-parallel来提升uglifyPlugin的压缩速度。原理上 webpack-uglify-parallel 采⽤了多核并⾏压缩来提升压缩速度

4.vite的劣势：

　　a. 生态不及webpack，加载器、插件不够丰富

　　b. 打包到生产环境时，vite使用了传统的rollup(也可以自己手动安装webpack来)进行打包

　　c.项目的开发浏览器要支持ESmodule，而且不能识别CommonJS语法

https://www.cnblogs.com/felix-felix/p/17131335.html

• 你的 git 工作流是怎样的?

Git是一个分布式版本控制系统，可以支持多种工作流程。以下是一种常见的Git工作流程：

集中式工作流：该工作流程使用一个中央仓库作为代码存储库。开发人员从中央仓库中克隆代码，并在本地工作副本中修改代码。然后将修改后的代码推送到中央仓库中进行合并。该工作流程适用于小型团队或单人开发项目，因为该工作流程中没有必要进行分支管理。
功能分支工作流：该工作流程使用分支来开发新功能。每个新功能都在一个独立的分支上进行开发。开发人员在自己的本地副本中创建新的功能分支，修改代码，并将其推送到远程仓库中进行合并。一旦开发完成并通过测试后，将合并到主分支中。该工作流程适用于大型团队或复杂项目，因为它能够使不同开发人员独立开发新功能，而不会相互干扰。
Gitflow工作流：该工作流程扩展了功能分支工作流程，使用两个主分支：master分支和develop分支。Master分支包含了每个发布版本的代码。Develop分支包含了最新的开发版本代码。功能分支从Develop分支上派生出来，当功能开发完成并通过测试后，合并回Develop分支。当准备发布新版本时，从Develop分支派生出一个release分支，对该分支进行Bug修复和测试。一旦准备好发布，将该release分支合并到Master和Develop分支中。该工作流程适用于需要维护多个版本的软件项目。
Forking工作流：该工作流程使用代码Forking来管理多个不同的开发者之间的协作。每个开发人员都从主项目中Fork一个自己的副本，进行修改和开发。一旦开发完成，开发人员可以向主项目发送Pull Request，请求合并其修改。该工作流程适用于开源项目和跨组织协作的场景。

总之，Git支持多种工作流程，开发团队可以根据自己的需求选择合适的工作流程。无论哪种工作流程，使用Git作为版本控制系统能够提高代码协作效率，使开发过程更加高效和稳定。

git工作流 - 简书

GitFlow 工作流

GitFlow 是由 Vincent Driessen 提出的一个 git操作流程标准，包含如下几个关键分支：

master：主分支，非常稳定的，不用来开发和发布，只用来跟踪已经发布的代码；
develop：主开发分支，包含确定即将发布的代码；开发都在这个分支；
到发布时，再合并到release上；
feature：新功能分支，一般一个新功能对应一个分支，对于功能的拆分需要比较合理，以避免一些后面不必要的代码冲突；
release：发布分支，发布时候用的分支，测试时候发现的 bug直接在这个分支进行修复；
hotfix：热修复分支，紧急修 bug 的时候用；

在实际开发过程中，需要注意到以下几点：

master 线是最干净的分支，只有在发布版本的时候，才需要合并到此分支上。
dev 分支上面的代码一定是最新的，而且是可以协同使用的；没有开发完成的代码，请不要合并上去。dev 上面存放的是一个一个的开发任务，任务完成就提交到 dev，有新的任务过来时，就在 dev 上面新建一个 feature 分支。
如果这个新的任务 feature 上面，需要多个人同时协同开发，就在这个 feature 上面各自再建自己的分支。
如果多人协同的代码有交叉的，需要共享，这时就需要随时将自己最新的代码提交，merge到 feature 分支上，然后同步到远程，同时，其他开发人员也需要随时从远程 pull 最新的代码，并 merge 到自己开发的分支上。

GitFlow的好处

并行开发：

每个新功能都会建立一个新的 feature分支，从而和已经完成的功能隔离开来，而且只有在新功能完成开发的情况下，其对应的 feature分支才会合并到主开发分支（develop分支）

协作开发：

每个 feature分支多人协同开发。

发布阶段：

当 feature 开发完成的时候，它会被合并到 develop 分支，这个分支主要用来暂时保存那些还没有发布的内容，所以如果需要再开发新的 feature，我们只需要从 develop 分支创建新分支，即可包含所有已经完成的 feature 。

紧急修复：

hotfix（bug）分支，这种类型的分支是从master分支上创建出来并做一个紧急的修复，而且这个紧急修复只影响这个已经发布的版本，而不会影响到你正在开发的新 feature。

GitFlow 工作流_雾里看花叹朦胧的博客-优快云博客

Git版本管理完全指南 - 简书

https://www.cnblogs.com/cnblogsfans/p/5075073.html 这篇不错

• rebase 与 merge 的区别?

先上答案：

1.merge 会多出一次 merge commit，rebase不会。

2.merge 的提交树是非线性的，rebase 的提交树是线性的（通过重写提交历史）。

解析：

git rebase 和 git merge 一样都是用于从一个分支获取并且合并到当前分支.

假设一个场景,就是我们开发的[feature/todo]分支要合并到master主分支,那么用rebase或者merge有什么不同呢?

marge

特点：自动创建一个新的commit 如果合并的时候遇到冲突，仅需要修改后重新commit

优点：记录了真实的commit情况，包括每个分支的详情

缺点：因为每次merge会自动产生一个merge commit，所以在使用一些git 的GUI tools，特别是commit比较频繁时，看到分支很杂乱。

rebase

特点：会合并之前的commit历史

优点：得到更简洁的项目历史，去掉了merge commit

缺点：如果合并出现代码问题不容易定位，因为re-write了history

因此,当需要保留详细的合并信息的时候建议使用git merge，特别是需要将分支合并进入master分支时；当发现自己修改某个功能时，频繁进行了git commit提交时，发现其实过多的提交信息没有必要时，可以尝试git rebase.

git reset、git revert 和 git checkout 有什么区别

这个问题同样也需要先了解 git 仓库的三个组成部分：工作区（Working Directory）、暂存区（Stage）和历史记录区（History）。

工作区：在 git 管理下的正常目录都算是工作区，我们平时的编辑工作都是在工作区完成
暂存区：临时区域。里面存放将要提交文件的快照
历史记录区：git commit 后的记录区

三个区的转换关系以及转换所使用的命令：

git reset、git revert 和 git checkout的共同点：用来撤销代码仓库中的某些更改。

然后是不同点：

首先，从 commit 层面来说：

git reset 可以将一个分支的末端指向之前的一个 commit。然后再下次 git 执行垃圾回收的时候，会把这个 commit 之后的 commit 都扔掉。git reset 还支持三种标记，用来标记 reset 指令影响的范围：
–mixed：会影响到暂存区和历史记录区。也是默认选项
- –soft：只影响历史记录区
- –hard：影响工作区、暂存区和历史记录区

注意：因为 git reset 是直接删除 commit 记录，从而会影响到其他开发人员的分支，所以不要在公共分支（比如 develop）做这个操作。

- git checkout 可以将 HEAD 移到一个新的分支，并更新工作目录。因为可能会覆盖本地的修改，所以执行这个指令之前，你需要 stash 或者 commit 暂存区和工作区的更改。
git revert 和 git reset 的目的是一样的，但是做法不同，它会以创建新的 commit 的方式来撤销 commit，这样能保留之前的 commit 历史，比较安全。另外，同样因为可能会覆盖本地的修改，所以执行这个指令之前，你需要 stash 或者 commit 暂存区和工作区的更改。

然后，从文件层面来说：