高级web前端面试题.docx

高级web前端面试题 CSS工程化是为了解决以下问题： 宏观设计：CSS代码如何组织、如何拆分、模块结构怎样设计？ 编码优化：怎样写出更好的CSS？ 构建：如何处理我的CSS，才能让它的打包结果最优？ 可维护性：代码写完了，如何最小化它后续的变更成本？如何确保任何一个同事都能轻松接手？ 以下三个方向都是时下比较流行的、普适性非常好的CSS工程化实践： 预处理器：Less、Sass等； 重要的工程化插件：PostCss； Webpackloader等。 基于这三个方向，可以衍生出一些具有典型意义的子问题，这里我们逐个来看： （1）预处理器：为什么要用预处理器？它的出现是为了解决什么问题？ 预处理器，其实就是CSS世界的“轮子”。预处理器支持我们写一种类似CSS、但实际并不是CSS的语言，然后把它编译成CSS代码：那为什么写CSS代码写得好好的，偏偏要转去写“类CSS”呢？这就和本来用JS也可以实现所有功能，但最后却写React的? jsx?或者Vue的模板语法一样——为了爽！要想知道有了预处理器有多爽，首先要知道的是传统CSS有多不爽。随着前端业务复杂度的提高，前端工程中对CSS提出了以下的诉求： 宏观设计上：我们希望能优化CSS文件的目录结构，对现有的CSS文件实现复用； 编码优化上：我们希望能写出结构清晰、简明易懂的CSS，需要它具有一目了然的嵌套层级关系，而不是无差别的一铺到底写法；我们希望它具有变量特征、计算能力、循环能力等等更强的可编程性，这样我们可以少写一些无用的代码； 可维护性上：更强的可编程性意味着更优质的代码结构，实现复用意味着更简单的目录结构和更强的拓展能力，这两点如果能做到，自然会带来更强的可维护性。 这三点是传统CSS所做不到的，也正是预处理器所解决掉的问题。预处理器普遍会具备这样的特性： 嵌套代码的能力，通过嵌套来反映不同css属性之间的层级关系； 支持定义css变量； 提供计算函数； 允许对代码片段进行extend和mixin； 支持循环语句的使用； 支持将CSS文件模块化，实现复用。 （2）PostCss：PostCss是如何工作的？我们在什么场景下会使用PostCss？ 它和预处理器的不同就在于，预处理器处理的是类CSS，而? PostCss?处理的就是CSS本身。Babel可以将高版本的JS代码转换为低版本的JS代码。PostCss做的是类似的事情：它可以编译尚未被浏览器广泛支持的先进的CSS语法，还可以自动为一些需要额外兼容的语法增加前缀。更强的是，由于PostCss有着强大的插件机制，支持各种各样的扩展，极大地强化了CSS的能力。 PostCss在业务中的使用场景非常多： 提高CSS代码的可读性：PostCss其实可以做类似预处理器能做的工作； 当我们的CSS代码需要适配低版本浏览器时，PostCss的Autoprefixer插件可以帮助我们自动增加浏览器前缀； 允许我们编写面向未来的CSS：PostCss能够帮助我们编译CSSnext代码。 （3）Webpack能处理CSS吗？如何实现？?Webpack能处理CSS吗： 1.Webpack在裸奔的状态下，是不能处理CSS的，Webpack本身是一个面向JavaScript且只能处理JavaScript代码的模块化打包工具； 2.Webpack在loader的辅助下，是可以处理CSS的。 如何用Webpack实现对CSS的处理： Webpack中操作CSS需要使用的两个关键的loader：css-loader和style-loader 注意，答出“用什么”有时候可能还不够，面试官会怀疑你是不是在背答案，所以你还需要了解每个loader都做了什么事情： css-loader：导入CSS模块，对CSS代码进行编译处理； style-loader：创建style标签，把CSS内容写入标签。 在实际使用中，css-loader的执行顺序一定要安排在style-loader的前面。因为只有完成了编译过程，才可以对css代码进行插入；若提前插入了未编译的代码，那么webpack是无法理解这坨东西的，它会无情报错。