前端 面试 小总结
一、常见的模块化构建工具 webpack
答：Gulp、Grunt、Webpack
1.Grunt和Gulp都是前端自动化构建工具，可以进行文件的合并压缩，但是gulp比grunt更高效，因为它可以支持异步多任务，更易于使用，插件也有更高的质量
2.Webpack是前端资源模块化管理和打包工具，是一个模块打包器，在他的视野里，前端所有的资源文件都会作为模块处理它将根据模块的依赖关系，生成对应的静态资源
3.webpack的工作方式是：将项目看成一个整体，通过一个给定的主文件，比如index.js，Webpack将从这个文件开始找到项目里的所有依赖文件，使用loaders处理他们，最后打包为一个(或多个)浏览器可识别的Javascript文件
4.与gulp和grunt相比，Webpack处理速度更快，能打包不同类型的文件，更重要的是，webpack是一个模块化打包工具，gulp和grunt也高度依赖插件
二、Webpack的四个核心概念：入口(entry)，输出(output)、loader、插件(plugin)
(1)入口(entry)：指示webpack应该使用哪个模块，来作为构建其内部依赖图的开始，进入起点入口以后，webpack会找出哪些模块和库是入口起点(直接和间接)依赖的
(2)输出(output)：告诉webpack在哪里输出他所创建的bundles，以及如何命名这些文件，默认为./dist，基本上，整个应用程序结构，都会被编译到你指定的输出路径的文件夹
(3)loader：让webpack去处理那些非JS文件(webpack本身只理解JS)，loader可以将所有类型文件转换为webpack能够处理的有效模块，然后就可以利用
webpack的打包能力，对他们进行处理
(4) 插件：使用时，require引入，然后把它添加到plugins数组中
三、webpack两大特色：1.可以自动完成；2.loader可以处理各种类型的静态文件，并且支持串联操作； 3.webpack是以commonJS的形式来书写的，但对AMD/CMD支持也很全面
四、position有哪些属性
1.absolute：生成绝对定位元素，相对于最近一级的定位不是static的父元素来进行定位
2.fixed：(老IE不支持)生成绝对定位的元素，通常对于浏览器窗口或frame进行定位
3.relative：生成相对定位的元素，相对于其在普通流中的位置进行定位
4.static：默认值，没有定位，元素出现在正常流中
5.sticky：生成粘性定位的元素，容器的位置根据正常文档流计算得知
五、TCP和UDP的区别
1.TCP处于传输层的协议，是传输控制协议，是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接，一个TCP连接必须要经过三次对话才能建立起来
2.UDP：用户数据报协议，是与TCP相对应的协议，他是面向非连接的协议，他不与对方建立连接，而是直接把数据包发送过去，UDP适用于一次只传少量数据，对可靠性要求不高的应用环境
区别：
(1)TCP面向有连接，UDP面向无连接
(2)TCP可靠，UDP不可靠
(3)TCP有序，UDP无序，消息在传输过程中可能会乱序，后发送的可能先达
(4)TCP无界，UDP有界，TCP通过字节流转，UDP中每个包是单独的
(5)TCP有流量控制(拥塞控制，三次握手)，UDP没有
(6)TCP传输慢，UDP传输快，视频流，广播电视，在线多媒体都使用UDP
(7)TCP是重量级的，UDP是轻量级的
(8)TCP头部比UDP大，TCP头需20个字节，UDP头只需8个字节
六、浏览器缓存
浏览器缓存分为强缓存和协商缓存，当客户端请求某个资源的时候，获取缓存的流程如下：
1.先根据这个资源的一些http header判断她是否命中强缓存，如果命中，则直接从本地获取缓存资源，不会发送请求到服务端
2.当强缓存没有命中的时候，客户端会发送请求到服务器，服务器通过另一些request header验证这个资源是否命中协商缓存，称为http再验证，如果命中，服务器将请求返回，但不返回资源，而是告诉客户端直接从缓存中获取，客户端收到返回后从缓存中获取
3.强缓存和协商缓存的共同之处在于，如果命中缓存，服务器都不会返回资源
区别是：
1.强缓存不会发送请求到服务器，但协商缓存会
2.当ctrl+f5 强制刷新网页时，直接从服务器加载，跳过强缓存和协商缓存
3.当f5刷新网页时，跳过强缓存，但是会检查协商缓存
强缓存：(以最新的为准)
(1)Expires：(http1.0的规范) 缓存过期时间
(2)Cache-Control：max-age(http1.1规范) 缓存资源的最大生命周期
协商缓存：
(1)Last-Modified：最后更新时间，随服务器response返回
(2)If-Modified-Since：发起请求使用的；通过比较两个时间来判断资源在两次请求期间是否有过修改，如果没有修改，则命中协商缓存
(3)ETag：资源内容的唯一标识，随服务器返回
(4)If-None-Match：服务器通过比较请求头部的If-None-Match与当前资源的ETag是否一致来判断资源是否在两次请求之间修改过
如果没有修改，则命中协商缓存
七、React的生命周期
我认为React的生命周期可以从三个方向考虑：
1.初次渲染的时候：Constructor=>getDefaultProps=>getInitialState=>ComponentWillMount=>render=>ComponentDidMount
2.第二次渲染的时候：getInitialState=>ComponentWillMount=>render=>ComponentDidMount
3.父组件props改变的时候：ComponentWillReceiveProps=>shouldComponentUpdate=>CompomentWillUpdate=>render=>ComponentDidUpdate
4.组件自身内部state改变的时候(this.setState)：shouldComponentUpdate=>ComponentWillUpdate=>render=>ComponentDidUpdate
5.最终在取消挂载的时候，都会执行ComponentWillUnMount
八、React的pureComponent和Component的区别
1.pureComponent是浅比较，只比较引用类型的地址是否一样，而不比较其中的值是否还一样
九、redux的实现原理
redux的实现原理(store，action，reducer)
1.触发一个action
2.视图发出一个action，action creater将这个action格式化并返回
3.这个action要么被自动dispatch(配置时候使用bindActionCreators())，要么由视图层手动dispatch
4.store接收到这个action后，将当前的状态树和action传给根reducer
5.根reducer将整个状态树切分成一个个小块，然后将某一个小块分发给知道怎么处理这个小块的子reducer
6.子reducer将传入的小块状态树进行拷贝，然后在副本上修改，并最终将修改后的副本返回给根reducer
7.当所有的子reducer返回他们修改好的副本后，根reducer将这些部分再次组合成一颗新的状态树，然后根reducer将这个新状态树交还给store，store再将自己的状态设置为这个新的状态树
8.store告诉视图层，状态更新了
9.视图层绑定让store把更新的状态传过来
10.视图层绑定触发了一个重新渲染的操作
设置redux:
(1)准备好store，根组件会创建store，并通过createStore(reducer)方法告诉store该使用哪一个根reducer，与此同时，根reducer也通过combineReducer()方法创建了一个向自己汇报的reducer团队
(2)设置store和组件之间的通信。根组件将她的所有子组件包裹在
(3)准备好action callback，为了让木偶组件更好的处理action，智能组件可以使用bindActionCreators()方法来创建action callback。这样做以后智能组件(容器型组件)就能给木偶组件(展示型组件)传入一个回调，对应的action会在木偶组件调用这个回调的时候被自动dispatch
十、虚拟DOM DIFF
虚拟DOM实现，优点及原理，DIFF算法原理：
Diff算法有三个策略：
(1)(render tree)Web UI中DOM节点跨层次移动操作很少，可以忽略不计
(2)(component tree)拥有相同类的两个组件会生成相似的树型结构,拥有不同类的两个组件会生成不同的树形结构
(3) 对于同一层次的一组子节点，他们可以通过唯一的id进行区分
十一、Bind / call / apply的区别
1.这三个函数都是改变this的指向，第一个参数都是this,
2.call和apply比较类似，不同的是第二个参数，call接受的参数必须一个一个分开放入，apply的参数写成一个数组
3.bind() 方法和前两者不同在于： bind() 方法会返回执行上下文被改变的函数而不会立即执行，而前两者是直接执行该函数。他的参数和call()相同。
十二、前端渲染和服务端渲染（ssr）区别
（一）前端渲染路线：1. 请求一个html -> 2. 服务端返回一个html -> 3. 浏览器下载html里面的js/css文件 -> 4. 等待js文件下载完成 -> 5. 等待js加载并初始化完成 -> 6. js代码终于可以运行，由js代码向后端请求数据( ajax/fetch ) -> 7. 等待后端数据返回 -> 8. react-dom( 客户端 )从无到完整地，把数据渲染为响应页面
（二）服务端渲染路线：2. 请求一个html -> 2. 服务端请求数据( 内网请求快 ) -> 3. 服务器初始渲染（服务端性能好，较快） -> 4. 服务端返回已经有正确内容的页面 -> 5. 客户端请求js/css文件 -> 6. 等待js文件下载完成 -> 7. 等待js加载并初始化完成 -> 8. react-dom( 客户端 )把剩下一部分渲染完成( 内容小，渲染快 )
SSR即服务端渲染，简单理解是将组件或页面通过服务器生成html字符串，再发送到浏览器。与SPA相比，服务端渲染的优势在于：利于SEO，减少页面首屏加载时间。但是服务端渲染对服务器的压力也是相对较大的，和服务器简单输出静态文件相比，通过node去渲染出页面再传递给客户端显然开销是比较大的，需要注意准备好相应的服务器负载。