最后
小编的一位同事在校期间连续三年参加ACM-ICPC竞赛。从参赛开始，原计划每天刷一道算法题，实际上每天有时候不止一题，一年最终完成了 600+：
凭借三年刷题经验，他在校招中很快拿到了各大公司的offer。
入职前，他把他的刷题经验总结成1121页PDF书籍，作为礼物赠送给他的学弟学妹，希望同学们都能在最短时间内掌握校招常见的算法及解题思路。
整本书，我仔细看了一遍，作者非常细心地将常见核心算法题和汇总题拆分为4个章节。
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
而对于有时间的同学，作者还给出了他结合众多数据结构算法书籍，挑选出的一千多道题的解题思路和方法，以供有需要的同学慢慢研究。
写在前面的一些话
从我上大学开始正式认识前端这个岗位到现在已经整整过了六年，这六年于我而言就像是观赏了一场盛大的游园活动。无数各式各样的框架、模式、开发思路如同花车一般从眼前掠过又走远。留下了一地残乱的余烬和破碎的思考。
当我抬头的时候，发现这已经是余留MVVM的时代。vue和react大行其道，刚刚毕业的同学们仿佛已经默认不会这俩框架之一就找不到工作。在面试的时候他们面对相关的提问也能娓娓道来，让他们阐述源码中的一些原理也同样能胜任。
但是，源码的原理永远是一层浮于表象的阐述，你未曾一点点认真的追踪每一个步骤，也未曾在框架设计的时候渗入自己的思考和提案，更不曾去了解框架被设计和迭代时的需求和背景。如此一来,你了解的永远只能是 HOW，而不是背后真正重要的 WHY。
这几天听阿里的P8止水大佬说过，在大部分情况下，p7以上的技术实力并无太大的区别，能以技术实力走上代码巅峰的人寥寥无几，更多的代码攀登者将以思考的方式去进步，因此他们去拓宽他们视野，去了解代码演进的历程，去预判未来的趋势。而这，绝不是仅仅明白 HOW就能到的。
现在的我，只是一个两年半经验的小前端。但工作经验并不会对技术的喜爱和思考产生一丝一毫的障碍。计算机是现代社会进程中真正的魔法，而我们，则是掌控这魔法的魔法师，参破魔法背后的奥秘，在代码的巴别塔上留下我们的痕迹，应是吾辈所求。
从DOM到虚拟DOM，我们应该提出哪些问题？
在如今面向面试学习的大氛围下，我们最常用被问到的关于虚拟DOM的问题是：
“什么是虚拟DOM？”
“为什么要用虚拟DOM？”
第一个问题其实比较好解答，个人觉得比较好的回答是：“虚拟DOM本质上是一组JS到DOM的映射，他在表现形式上呈现为一个包含了所有DOM所需信息的JS对象。”其实一般而言，是什么之类的问题会比较好解答。因为你只需要描述他，而为什么之类的问题就往往难以下口，因为其往往内部蕴含这很多很多延伸的信息。
于是乎在我听到看到过对于第二个问题的解答中，最多的是：“选择使用虚拟DOM的原因是因为直接操作DOM节点的代价太昂贵，而操作JS的成本就要小的多，直接操作DOM节点会引起浏览器的回流重绘，JS则可以发挥他的优势自由选择操作时机和方式。”
但真的仅仅是如此吗？
让我们拉开我们的视野，不再死盯着虚拟DOM这一个单词，而是回望整个前端高速迭代的这几年，重新思考一下以下这些问题。
-
在没有虚拟DOM前，我们经历了什么？
-
是什么让程序员们萌生了使用虚拟DOM的想法？
-
虚拟DOM的优势到底是什么，是什么让它成为了时代的选择？
-
是什么推动了前端职能和功能的高速发展？
身为前端，我们经历了什么？
当我参加工作时，其实vue与react已经成为主流，虽说不像如今这般火爆，但也是妥妥的加分项目。页面的需求和职能已经相当复杂。让我们时光倒退，从头来看这前端人的发展历程。
静态页面与切图——低需求下的低要求
从前（听说的），有这么一个年代，前端同学们最麻烦的工作是切图，最枯燥的任务是搓DOM，所以又被成为切图仔…
那时候只有一些初级版本的js框架，包括但不限于prototype，开发者靠着大量手搓DOM和原生JS实现一些简单的交互，高端的操作可能会事扒脚本，扒组件以实现自己的功能。
这个时期的前端开发者很纯粹，那时尚未开始前后端分离的进程，开发者要做的就是将页面合理的呈现出来，以及实现不多的交互需求。
JQ时代——日益增长的需求与低下开发效率的矛盾
一件事物一旦出现，历史的浪潮就会裹挟着它不断的向前进步。很快的，人们对于页面的要求不再是单纯的能用就行——他们需要更加炫酷的交互，这为前端工程师们带来了难题，究其原因，还是因为那时原生的jsapi实在是又缺又难用。于是，JQ等一大批js框架便应运而生了。
同时代的框架包括但不限于JQ，Dojo，prototype等等，这些对于年轻的前端工程师们来说无疑已经是近乎古董的代名词。可是在当时那个年代，后浏览器战争时代带来的后遗症——兼容性问题已经是折磨当时工程师们的主要凶手（当然现在也是，但在越来越丰富的插件辅助下已经缓解许多）。JQ凭借着其优异的兼容性和性能，在一代js框架中占据了主流。
从当今的眼光来看，JQ依然是不可多得的好框架，得益于Sizzle选择器引擎的研发成功，其性能有了质的突破。它将编写前端代码从后端操纵类的思维中脱离出来，便携式的获取一个或一组DOM节点，并且提供了链式调用。前端开发者们不再需要费劲心思的去想着怎么去合理的操作DOM，他们只要关心业务逻辑的实现即可。
JQ时代是需求和效率第一次大型冲突的产物，从此，解放生产力成为了前端工程师心中亘古不变的追求。
后JQ时代——进一步提升效率的模板语法
JQ和其高度发达的生态环境催生了JQ插件的高速发展，当时的前端开发者们想要实现一个功能，第一个反应就去搜插件，所以在当时的HTML文件内经常密密麻麻的插入了十几甚至几十的<script>标签，这不仅让页面变的臃肿不堪，更带来了全局变量污染的问题和性能问题（例如经典的白屏问题）。
受累于不同素质的开发者（插件素质层次不齐）以及日益庞大的插件库所带来的全局变量污染问题，前端开发者们从后端同胞的代码中得到了启发——他们也想要模块化。
在那个年代，javaScript尚没有import和export 这样的标准化支持，于是他们便自己建立了一个标准，那就是CommonJs。当然，之后还有分裂出AMD，CMD等等。这为后来Node.js的蓬勃发展埋下了伏笔。模块化相关知识与本文主旨关系不大，所以不展开细说。
同时JQ也没能很好的解决循环插入DOM节点的需求，拼接数据组成的DOM字符串让开发者们叫苦不迭。于是乎模版语法也运营而生了。用一个经典的公式来概括，那就是：
HTML = template(data)
可以看出，template其实就是一种将数据转为DOM的规则——而且能自定义！而template的原理其实很简单，大致分为以下几步：
-
接受数据，解析他们
-
填入模板
-
innerHtml
在解决了循环插入DOM节点的需求后前端工程师们发现了模板语法更大的优点——你要做的只是数据到DOM节点的映射，不用去点对点的操作DOM，不用关心数据如何变化，你只需要控制规则。兴许是从那一刻开始，前端开发者们寻到了一个崭新而又正确的发展方向——数据驱动。
但模版语法也有他的缺点。说白了，他只是一个数据的解析器，你不可能指望他去解决多么复杂炫酷的问题。而且在早期的模板语法中，他的更新会将所有dom节点注销，然后生成完整的新节点再插入页面中。这样大批量的操作dom必然会导致性能问题——操作dom的开销实在是太大了，何况是一整个页面的的dom呢？
于是乎开发者们在写的爽和用的爽之间陷入了两难，但用的不爽是绝对不行的（你懂的），于是乎也不知是哪一位大佬突然在某天拍案而起，操作dom开销那么大，我操作js不就行了！
三大框架时代——虚拟DOM的狂飙
操作dom开销那么大，我操作js不就行了？
这个疯狂却又合理想法一旦产生就再也无法扑灭，因为这太适合js了。js在诞生之初就可以操作DOM的本能，而js本身的能力又那么强大，模板语法的缺点它完全可以消化和包容，包括但不限于差量更新 ，批量更新等一系列梦寐以求的可以提高渲染性能的手段终于可以提上日程了。
于是，新世界的大门就此打开。
至此，我们来明确一点，虚拟DOM，正是作为数据和真实DOM之间的缓冲诞生。
React
-
介绍一下react
-
React单项数据流
-
react生命周期函数和react组件的生命周期
-
react和Vue的原理，区别，亮点，作用
-
reactJs的组件交流
-
有了解过react的虚拟DOM吗，虚拟DOM是怎么对比的呢
-
项目里用到了react，为什么要选择react，react有哪些好处
-
怎么获取真正的dom
-
选择react的原因
-
react的生命周期函数
-
setState之后的流程
-
react高阶组件知道吗？
-
React的jsx，函数式编程
-
react的组件是通过什么去判断是否刷新的
-
如何配置React-Router
-
路由的动态加载模块
-
Redux中间件是什么东西，接受几个参数
-
redux请求中间件如何处理并发
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
583
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
