九、Webpack 篇

1. 谈谈你对Webpack的理解（Webpack是什么？）

Webpack 是一个 静态模块打包器，可以分析各个模块的依赖关系，项目中的所有资源皆为模块，通过分析模块间的依赖关系，在其内部递归构建出一个依赖关系图，其中包含应用程序需要的每个模块，然后将这些模块打包成一个或多个 bundle。最终编绎输出模块为 HTML、JavaScript、CSS 以及各种静态文件（图片、字体等）。

webpack 就像一条生产线,要经过一系列处理流程(loader)后才能将源文件转换成输出结果。 这条生产线上的每个处理流程的职责都是单一的,多个流程之间有存在依赖关系,只有完成当前处理后才能交给下一个流程去处理。

插件就像是一个插入到生产线中的一个功能,在特定的时机对生产线上的资源做处理。 webpack 在运行过程中会广播事件,插件只需要监听它所关心的事件,就能加入到这条生产线中,去改变生产线的运作。

webpack的主要作用如下：

模块打包 可以将不同模块的文件打包整合在一起，并且保证它们之间的引用正确，执行有序。利用打包我们就可以在开发的时候根据我们自己的业务自由划分文件模块，保证项目结构的清晰和可读性。

编译兼容 在前端的“上古时期”，手写一堆浏览器兼容代码一直是令前端工程师头皮发麻的事情，而在今天这个问题被大大的弱化了，通过webpack的Loader机制，不仅仅可以帮助我们对代码做polyfill，还可以编译转换诸如.less，.vue，.jsx这类在浏览器无法识别的格式文件，让我们在开发的时候可以使用新特性和新语法做开发，提高开发效率。

能力扩展 通过webpack的Plugin机制，我们在实现模块化打包和编译兼容的基础上，可以进一步实现诸如按需加载，代码压缩等一系列功能，帮助我们进一步提高自动化程度，工程效率以及打包输出的质量。

2. Webpack的打包过程/打包原理/构建流程？

初始化：启动构建，读取与合并配置参数，加载plugin,实例化Compiler

编译：从Entry出发，针对每个Module串行调用对应的Loader去翻译文件中的内容，再找到该Module依赖的Module，递归的进行编译处理

输出：将编译后的Module组合成Chunk,将Chunk转换成文件，输出到文件系统中

细节：

Webpack CLI 通过 yargs模块解析 CLI 参数，并转化为配置对象option（单入口：Object，多入口：Array），调用 webpack(option) 创建 compiler 对象。

如果有 option.plugin，则遍历调用plugin.apply()来注册 plugin，

判断是否开启了 watch，如果开启则调用 compiler.watch，否则调用 compiler.run，开始构建。

创建 Compilation 对象来收集全部资源和信息，然后触发 make 钩子。

make阶段从入口开始递归所有依赖，

每次遍历时调用对应Loader翻译文件中内容，然后生成AST，遍历AST找到下个依赖继续递归，

根据入口和模块之间关系组装chunk，输出到dist中的一个文件内。

在以上过程中，webpack会在特定的时间点（使用tapable模块）广播特定的事件，插件监听事件并执行相应的逻辑，并且插件可以调用webpack提供的api改变webpack的运行结果

3. loader的作用

webpack中的loader是一个函数，主要为了实现源码的转换，所以loader函数会以源码作为参数，比如，将ES6转换为ES5，将less转换为css，然后再将css转换为js，以便能嵌入到html文件中。

默认情况下，webpack只支持对js和json文件进行打包，但是像css、html、png等其他类型的文件，webpack则无能为力。因此，就需要配置相应的loader进行文件内容的解析转换。

4. 有哪些常见的Loader？他们是解决什么问题的？

常用的loader如下：

image-loader：加载并且压缩图片文件。

less-loader：加载并编译 LESS 文件。

sass-loader：加载并编译 SASS/SCSS 文件。

css-loader：加载 CSS，支持模块化、压缩、文件导入等特性，使用css-loader必须要配合使用style-loader。

style-loader：用于将 CSS 编译完成的样式，挂载到页面的 style 标签上。需要注意 loader 执行顺序，style-loader 要放在第一位，loader 都是从后往前执行。

babel-loader：把 ES6 转换成 ES5

postcss-loader：扩展 CSS 语法，使用下一代 CSS，可以配合 autoprefixer 插件自动补齐 CSS3 前缀。

eslint-loader：通过 ESLint 检查 JavaScript 代码。

vue-loader：加载并编译 Vue 组件。

file-loader：把文件输出到一个文件夹中，在代码中通过相对 URL 去引用输出的文件 (处理图片和字体)

url-loader：与 file-loader 类似，区别是用户可以设置一个阈值，大于阈值会交给 file-loader 处理，小于阈值时返回文件 base64 形式编码 (处理图片和字体)。

source-map-loader：加载额外的 Source Map 文件，以方便断点调试。

5. plugin的作用

plugin是一个类，类中有一个apply()方法，主要用于Plugin的安装，可以在其中监听一些来自编译器发出的事件，在合适的时机做一些事情。

webpack中的plugin赋予其各种灵活的功能，例如打包优化、资源管理、环境变量注入等，它们会运行在webpack的不同阶段（钩子 / 生命周期），贯穿了webpack整个编译周期。目的在于「解决 loader 无法实现的其他事」。

6. 有哪些常见的Plugin？他们是解决什么问题的？

html-webpack-plugin：可以复制一个有结构的html文件，并自动引入打包输出的所有资源（JS/CSS）

clean-webpack-plugin：重新打包自动清空 dist 目录

mini-css-extract-plugin：提取 js 中的 css 成单独文件

optimize-css-assets-webpack-plugin：压缩css

uglifyjs-webpack-plugin：压缩js

commons-chunk-plugin：提取公共代码

define-plugin：定义环境变量

7. Webpack中Loader和Plugin的区别

运行时机

1.loader运行在编译阶段

2.plugins 在整个周期都起作用

使用方式

Loader:1.下载 2.使用

Plugin:1.下载 2.引用 3.使用

loader是文件加载器，能够加载资源文件，并对这些文件进行一些处理，诸如编译、压缩等，最终一起打包到指定的文件中；plugin赋予了webpack各种灵活的功能，例如打包优化、资源管理、环境变量注入等，目的是解决 loader无法实现的其他事。

在运行时机上，loader 运行在打包文件之前；plugin则是在整个编译周期都起作用。

在配置上，loader在module.rules中配置，作为模块的解析规则，类型为数组。每一项都是一个 Object，内部包含了 test(类型文件)、loader、options (参数)等属性；plugin在 plugins中单独配置，类型为数组，每一项是一个 plugin 的实例，参数都通过构造函数传入。

8. webpack的热更新是如何做到的？说明其原理？

热更新的核心就是客户端从服务端拉去更新后的文件，准确的说是 chunk diff (chunk 需要更新的部分)，实际上webpack-dev-server与浏览器之间维护了一个websocket，当本地资源发生变化时，webpack-dev-server会向浏览器推送更新，并带上构建时的hash，让客户端与上一次资源进行对比。客户端对比出差异后会向webpack-dev-server发起 Ajax 请求来获取更改内容(文件列表、hash)，这样客户端就可以再借助这些信息继续向webpack-dev-server发起 jsonp 请求获取该chunk的增量更新。

后续的部分(拿到增量更新之后如何处理？哪些状态该保留？哪些又需要更新？)由HotModulePlugin 来完成，提供了相关 API 以供开发者针对自身场景进行处理，像react-hot-loader和vue-loader都是借助这些 API 实现热更新。

详细：

1、在 webpack 的 watch 模式下，文件系统中某一个文件发生修改，webpack 监听到文件变化，根据配置文件对模块重新编译打包，并将打包后的代码通过简单的 JavaScript 对象保存在内存中。

2、webpack-dev-server 和 webpack 之间的接口交互，而在这一步，主要是 dev-server 的中间件webpack-dev-middleware 和 webpack 之间的交互，webpack-dev-middleware 调用 webpack 暴露的 API对代码变化进行监控，并且告诉 webpack，将代码打包到内存中。

3、webpack-dev-server 对文件变化的一个监控，这一步不同于第一步，并不是监控代码变化重新打包。当我们在配置文件中配置了devServer.watchContentBase 为 true 的时候，Server 会监听这些配置文件夹中静态文件的变化，变化后会通知浏览器端对应用进行 live reload。注意，这儿是浏览器刷新，和 HMR 是两个概念

4、webpack-dev-server 代码的工作，该步骤主要是通过 sockjs（webpack-dev-server 的依赖）在浏览器端和服务端之间建立一个 websocket 长连接，将 webpack 编译打包的各个阶段的状态信息告知浏览器端，

同时也包括第三步中 Server 监听静态文件变化的信息。浏览器端根据这些 socket 消息进行不同的操作。当然服务端传递的最主要信息还是新模块的 hash 值，后面的步骤根据这一 hash 值来进行模块热替换。

webpack-dev-server/client 端并不能够请求更新的代码，也不会执行热更模块操作，而把这些工作又交回给了 webpack，webpack/hot/dev-server 的工作就是根据 webpack-dev-server/client 传给它的信息以及 dev-server 的配置决定是刷新浏览器呢还是进行模块热更新。当然如果仅仅是刷新浏览器，也就没有后面那些步骤了。HotModuleReplacement.runtime 是客户端 HMR 的中枢，它接收到上一步传递给他的新模块的 hash 值，它通过 JsonpMainTemplate.runtime 向 server 端发送 Ajax 请求，服务端返回一个 json，该 json 包含了所有要更新的模块的 hash 值，获取到更新列表后，该模块再次通过 jsonp 请求，获取到最新的模块代码。

5、决定 HMR 成功与否的关键步骤，在该步骤中，HotModulePlugin 将会对新旧模块进行对比，决定是否更新模块，在决定更新模块后，检查模块之间的依赖关系，更新模块的同时更新模块间的依赖引用。最后一步，当 HMR 失败后，回退到 live reload 操作，也就是进行浏览器刷新来获取最新打包代码。

9. 如何解决循环依赖问题

Webpack 中将 require 替换为 *webpack_require*，会根据 moduleId 到 installedModules 找是否加载过，加载过则直接返回之前的 export，不会重复加载。

10. 如何提高Webpack构建速度

1. 代码压缩

JS 压缩

webpack 4.0默认在生产环境的时候是支持代码压缩的，即mode=production模式下。实际上webpack 4.0默认是使用terser-webpack-plugin这个压缩插件，在此之前是使用 uglifyjs-webpack-plugin，两者的区别是后者对 ES6 的压缩不是很好，同时我们可以开启 parallel参数，使用多进程压缩，加快压缩。

CSS 压缩

CSS 压缩通常是去除无用的空格等，因为很难去修改选择器、属性的名称、值等。可以使用另外一个插件：css-minimizer-webpack-plugin。

HTML 压缩

使用HtmlWebpackPlugin插件来生成 HTML 的模板时候，通过配置属性minify进行 html 优化。

module.exports = {
plugin:[
  new HtmlwebpackPlugin({
    minify:{
      minifyCSS: false, // 是否压缩css
      collapseWhitespace: false, // 是否折叠空格
      removeComments: true // 是否移除注释
    }
  })
  ]
}

2. 图片压缩

配置image-webpack-loader

3. Tree Shaking

Tree Shaking是一个术语，在计算机中表示消除死代码，依赖于 ES Module 的静态语法分析（不执行任何的代码，可以明确知道模块的依赖关系）。在webpack实现Tree shaking有两种方案：

module.exports = {
    ...
    optimization:{
        usedExports
    }
  }

使用之后，没被用上的代码在webpack打包中会加入unused harmony export mul注释，用来告知Terser在优化时，可以删除掉这段代码。

sideEffects：跳过整个模块/文件，直接查看该文件是否有副作用

sideEffects用于告知webpack compiler哪些模块时有副作用，配置方法是在package.json中设置sideEffects属性。如果sideEffects设置为false，就是告知webpack可以安全的删除未用到的exports。如果有些文件需要保留，可以设置为数组的形式，如：

"sideEffecis":[
    "./src/util/format.js",
    "*.css" // 所有的css文件
]

4. 缩小打包域

排除webpack不需要解析的模块，即在使用loader的时候，在尽量少的模块中去使用。可以借助 include和exclude这两个参数，规定loader只在那些模块应用和在哪些模块不应用。

5. 减少 ES6 转为 ES5 的冗余代码

使用bable-plugin-transform-runtime插件

6. 提取公共代码

通过配置CommonsChunkPlugin插件，将多个页面的公共代码抽离成单独的文件

7. 其他

组件懒加载、路由懒加载、开启gzip、公共的第三方包上cdn、配置cache缓存Loader对文件的编译副本、配置resolve提高文件的搜索速度（@: src）

十、性能优化篇

1. 浏览器缓存优化

为了让浏览器缓存发挥最大作用，该策略尽量遵循以下五点就能发挥浏览器缓存最大作用。

「考虑拒绝一切缓存策略」：Cache-Control:no-store

「考虑资源是否每次向服务器请求」：Cache-Control:no-cache

「考虑资源是否被代理服务器缓存」：Cache-Control:public/private

「考虑资源过期时间」：Expires:t/Cache-Control:max-age=t,s-maxage=t

「考虑协商缓存」：Last-Modified/Etag

缓存策略通过设置HTTP报文实现，在形式上分为**「强缓存/强制缓存」和「协商缓存/对比缓存」**。为了方便对比，笔者将某些细节使用图例展示，相信你有更好的理解。

整个缓存策略机制很明了，先走强缓存，若命中失败才走协商缓存。若命中强缓存，直接使用强缓存；若未命中强缓存，发送请求到服务器检查是否命中协商缓存；若命中协商缓存，服务器返回304通知浏览器使用本地缓存，否则返回最新资源。

有两种较常用的应用场景值得使用缓存策略一试，当然更多应用场景都可根据项目需求制定。

「频繁变动资源」：设置Cache-Control:no-cache，使浏览器每次都发送请求到服务器，配合Last-Modified/ETag验证资源是否有效

「不常变化资源」：设置Cache-Control:max-age=31536000，对文件名哈希处理，当代码修改后生成新的文件名，当HTML文件引入文件名发生改变才会下载最新文件

2. 渲染层面性能优化

**「渲染层面」**的性能优化，无疑是如何让代码解析更好执行更快。因此笔者从以下五方面做出建议。

「CSS策略」：基于CSS规则

「DOM策略」：基于DOM操作

「阻塞策略」：基于脚本加载

「回流重绘策略」：基于回流重绘

「异步更新策略」：基于异步更新

上述五方面都是编写代码时完成，充满在整个项目流程的开发阶段里。因此在开发阶段需时刻注意以下涉及到的每一点，养成良好的开发习惯，性能优化也自然而然被使用上了。

渲染层面的性能优化更多表现在编码细节上，而并非实体代码。简单来说就是遵循某些编码规则，才能将渲染层面的性能优化发挥到最大作用。

**「回流重绘策略」**在渲染层面的性能优化里占比较重，也是最常规的性能优化之一。上年笔者发布的掘金小册《玩转CSS的艺术之美》使用一整章讲解回流重绘，本章已开通试读，更多细节请戳这里。

CSS策略

避免出现超过三层的嵌套规则

避免为ID选择器添加多余选择器

避免使用标签选择器代替类选择器

避免使用通配选择器，只对目标节点声明规则

避免重复匹配重复定义，关注可继承属性

DOM策略

缓存DOM计算属性

避免过多DOM操作

使用DOMFragment缓存批量化DOM操作

阻塞策略

脚本与DOM/其它脚本的依赖关系很强：对``设置defer

脚本与DOM/其它脚本的依赖关系不强：对``设置async

回流重绘策略

缓存DOM计算属性

使用类合并样式，避免逐条改变样式

使用display控制DOM显隐，将DOM离线化

异步更新策略

在异步任务中修改DOM时把其包装成微任务

3. 性能优化六大指标

六大指标基本囊括大部分性能优化细节，可作为九大策略的补充。笔者根据每条性能优化建议的特征将指标划分为以下六方面。

「加载优化」：资源在加载时可做的性能优化

「执行优化」：资源在执行时可做的性能优化

「渲染优化」：资源在渲染时可做的性能优化

「样式优化」：样式在编码时可做的性能优化

「脚本优化」：脚本在编码时可做的性能优化

「V8引擎优化」：针对V8引擎特征可做的性能优化

十一、其他杂项篇

1. 常见的浏览器内核有哪些？

主要分成两部分：渲染引擎(layout engineer或Rendering Engine)和JS引擎。

渲染引擎：负责取得网页的内容（HTML、XML、图像等等）、整理讯息（例如加入CSS等），以及计算网页的显示方式，然后会输出至显示器或打印机。浏览器的内核的不同对于网页的语法解释会有不同，所以渲染的效果也不相同。所有网页浏览器、电子邮件客户端以及其它需要编辑、显示网络内容的应用程序都需要内核。

JS引擎则：解析和执行javascript来实现网页的动态效果。

最开始渲染引擎和JS引擎并没有区分的很明确，后来JS引擎越来越独立，内核就倾向于只指渲染引擎。

常见内核

Trident 内核：IE, MaxThon, TT, The World, 360, 搜狗浏览器等。[又称 MSHTML]

Gecko 内核：Netscape6 及以上版本，FF, MozillaSuite / SeaMonkey 等

Presto 内核：Opera7 及以上。 [Opera内核原为：Presto，现为：Blink;]

Webkit 内核：Safari, Chrome等。 [ Chrome的：Blink（WebKit 的分支）]

2. 网页前端性能优化的方式有哪些？

1.压缩 css, js, 图片

2.减少 http 请求次数， 合并 css、js 、合并图片（雪碧图）

3.使用 CDN

4.减少 dom 元素数量

5.图片懒加载

6.静态资源另外用无 cookie 的域名

7.减少 dom 的访问（缓存 dom）

8.巧用事件委托

9.样式表置顶、脚本置低

3. 网页从输入网址到渲染完成经历了哪些过程？

大致可以分为如下7步：

输入网址；

发送到DNS服务器，并获取域名对应的web服务器对应的ip地址；

与web服务器建立TCP连接；

浏览器向web服务器发送http请求；

web服务器响应请求，并返回指定url的数据（或错误信息，或重定向的新的url地址）；

浏览器下载web服务器返回的数据及解析html源文件；

生成DOM树，解析css和js，渲染页面，直至显示完成；

4. 线程与进程的区别？

一个程序至少有一个进程,一个进程至少有一个线程.

线程的划分尺度小于进程，使得多线程程序的并发性高。

另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。

线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。

从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。

5. HTTP常见的状态码？

100 Continue 继续，一般在发送post请求时，已发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息

200 OK 正常返回信息

201 Created 请求成功并且服务器创建了新的资源

202 Accepted 服务器已接受请求，但尚未处理

301 Moved Permanently 请求的网页已永久移动到新位置。

302 Found 临时性重定向。

303 See Other 临时性重定向，且总是使用 GET 请求新的 URI。

304 Not Modified 自从上次请求后，请求的网页未修改过。

400 Bad Request 服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。

401 Unauthorized 请求未授权。

403 Forbidden 禁止访问。

404 Not Found 找不到如何与 URI 相匹配的资源。

500 Internal Server Error 最常见的服务器端错误。

503 Service Unavailable 服务器端暂时无法处理请求（可能是过载或维护）。

6. 图片懒加载？

当页面滚动的时间被触发 -> 执行加载图片操作 -> 判断图片是否在可视区域内 -> 在，则动态将data-src的值赋予该图片

7. 移动端性能优化？

尽量使用css3动画，开启硬件加速

适当使用touch时间代替click时间

避免使用css3渐变阴影效果

可以用transform: translateZ(0) 来开启硬件加速

不滥用float。float在渲染时计算量比较大，尽量减少使用

不滥用web字体。web字体需要下载，解析，重绘当前页面

合理使用requestAnimationFrame动画代替setTimeout

css中的属性（css3 transitions、css3 3D transforms、opacity、webGL、video）会触发GUP渲染，耗电

8. TCP 传输的三次握手、四次挥手策略

三次握手：

为了准确无误地吧数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出去后，TCP不会对传送后的情况置之不理，他一定会向对方确认是否送达，握手过程中使用TCP的标志：SYN和ACK

发送端首先发送一个带SYN的标志的数据包给对方

接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息

最后，发送端再回传一个带ACK的标志的数据包，代表“握手”结束

如在握手过程中某个阶段莫明中断，TCP协议会再次以相同的顺序发送相同的数据包

断开一个TCP连接需要“四次挥手”

第一次挥手：主动关闭方发送一个FIN，用来关注主动方到被动关闭方的数据传送，也即是主动关闭方告诫被动关闭方：我已经不会再给你发数据了（在FIN包之前发送的数据，如果没有收到对应的ACK确认报文，主动关闭方依然会重发这些数据）。但是，此时主动关闭方还可以接受数据

第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号收到序号 +1（与SYN相同，一个 FIN占用一个序号）

第三次挥手：被动关闭方发送一个 FIN。用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会给你发送数据了

第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手

9. HTTP 和 HTTPS，为什么HTTPS安全？

HTTP协议通常承载与 TCP协议之上，在HTTP和TCP之间添加一个安全协议层（SSL或TSL），这个时候，就成了我们常说的HTTPS

默认HTTP的端口号为80，HTTPS的端口号为443

因为网络请求需要中间有很多的服务器路由的转发，中间的节点都可能篡改信息，而如果使用HTTPS，密钥在你和终点站才有，https之所有说比http安全，是因为他利用ssl/tls协议传输。包含证书，流量转发，负载均衡，页面适配，浏览器适配，refer传递等，保障了传输过程的安全性

10. axios和fetch区别对比

axios 是一个基于Promise 用于浏览器和 nodejs 的 HTTP 客户端，本质上也是对原生XHR的封装，只不过它是Promise的实现版本，符合最新的ES规范，它本身具有以下特征

从浏览器中创建 XMLHttpRequest

支持 Promise API

客户端支持防止CSRF

提供了一些并发请求的接口（重要，方便了很多的操作）

从 node.js 创建 http 请求

拦截请求和响应

转换请求和响应数据

取消请求

自动转换JSON数据

fetch优势：

语法简洁，更加语义化

基于标准 Promise 实现，支持 async/await

同构方便，使用 isomorphic-fetch

更加底层，提供的API丰富（request, response）

脱离了XHR，是ES规范里新的实现方式

fetch存在问题

fetch是一个低层次的API，你可以把它考虑成原生的XHR，所以使用起来并不是那么舒服，需要进行封装。

fetch只对网络请求报错，对400，500都当做成功的请求，服务器返回 400，500 错误码时并不会 reject，只有网络错误这些导致请求不能完成时，fetch 才会被 reject。

fetch默认不会带cookie，需要添加配置项： fetch(url, {credentials: ‘include’})

fetch不支持abort，不支持超时控制，使用setTimeout及Promise.reject的实现的超时控制并不能阻止请求过程继续在后台运行，造成了流量的浪费

fetch没有办法原生监测请求的进度，而XHR可以

十二、主观题篇

1. 你都做过什么项目呢？具体聊某一个项目中运用的技术.

注意：用心找自己做的项目中自己感觉最拿出来手的（复杂度最高，用的技术最多的项目），描述的时候尽可能往里面添加一些技术名词

布局我们用html5+css3

我们会用reset.css重置浏览器的默认样式

JS框架的话我们选用的是jQuery(也可能是Zepto)

我们用版本控制工具git来协同开发

我们会基于gulp搭建的前端自动化工程来开发（里面包含有我们的项目结构、我们需要引用的第三方库等一些信息，我们还实现了sass编译、CSS3加前缀等的自动化）

我们的项目中还用到了表单验证validate插件、图片懒加载Lazyload插件

2. 你遇到过比较难的技术问题是？你是如何解决的？

3. 常使用的库有哪些？常用的前端开发工具？开发过什么应用或组件？

4. 除了前端以外还了解什么其它技术么？你最最厉害的技能是什么？

5. 对前端开发工程师这个职位是怎么样理解的？它的前景会怎么样？

前端是最贴近用户的程序员，比后端、数据库、产品经理、运营、安全都近。

1、实现界面交互

2、提升用户体验

3、有了Node.js，前端可以实现服务端的一些事情

前端是最贴近用户的程序员，前端的能力就是能让产品从 90分进化到 100 分，甚至更好，

参与项目，快速高质量完成实现效果图，精确到1px；

与团队成员，UI设计，产品经理的沟通；

做好的页面结构，页面重构和用户体验；

处理hack，兼容、写出优美的代码格式；

针对服务器的优化、拥抱最新前端技术。

你发送数据了

第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手

9. HTTP 和 HTTPS，为什么HTTPS安全？

HTTP协议通常承载与 TCP协议之上，在HTTP和TCP之间添加一个安全协议层（SSL或TSL），这个时候，就成了我们常说的HTTPS

默认HTTP的端口号为80，HTTPS的端口号为443

因为网络请求需要中间有很多的服务器路由的转发，中间的节点都可能篡改信息，而如果使用HTTPS，密钥在你和终点站才有，https之所有说比http安全，是因为他利用ssl/tls协议传输。包含证书，流量转发，负载均衡，页面适配，浏览器适配，refer传递等，保障了传输过程的安全性

10. axios和fetch区别对比

axios 是一个基于Promise 用于浏览器和 nodejs 的 HTTP 客户端，本质上也是对原生XHR的封装，只不过它是Promise的实现版本，符合最新的ES规范，它本身具有以下特征

从浏览器中创建 XMLHttpRequest

支持 Promise API

客户端支持防止CSRF

提供了一些并发请求的接口（重要，方便了很多的操作）

从 node.js 创建 http 请求

拦截请求和响应

转换请求和响应数据

取消请求

自动转换JSON数据

fetch优势：

语法简洁，更加语义化

基于标准 Promise 实现，支持 async/await

同构方便，使用 isomorphic-fetch

更加底层，提供的API丰富（request, response）

脱离了XHR，是ES规范里新的实现方式

fetch存在问题

fetch是一个低层次的API，你可以把它考虑成原生的XHR，所以使用起来并不是那么舒服，需要进行封装。

fetch只对网络请求报错，对400，500都当做成功的请求，服务器返回 400，500 错误码时并不会 reject，只有网络错误这些导致请求不能完成时，fetch 才会被 reject。

fetch默认不会带cookie，需要添加配置项： fetch(url, {credentials: ‘include’})

fetch不支持abort，不支持超时控制，使用setTimeout及Promise.reject的实现的超时控制并不能阻止请求过程继续在后台运行，造成了流量的浪费

fetch没有办法原生监测请求的进度，而XHR可以

十三、主观题篇

1. 你都做过什么项目呢？具体聊某一个项目中运用的技术.

注意：用心找自己做的项目中自己感觉最拿出来手的（复杂度最高，用的技术最多的项目），描述的时候尽可能往里面添加一些技术名词

布局我们用html5+css3

我们会用reset.css重置浏览器的默认样式

JS框架的话我们选用的是jQuery(也可能是Zepto)

我们用版本控制工具git来协同开发

我们会基于gulp搭建的前端自动化工程来开发（里面包含有我们的项目结构、我们需要引用的第三方库等一些信息，我们还实现了sass编译、CSS3加前缀等的自动化）

我们的项目中还用到了表单验证validate插件、图片懒加载Lazyload插件

2. 你遇到过比较难的技术问题是？你是如何解决的？

3. 常使用的库有哪些？常用的前端开发工具？开发过什么应用或组件？

4. 除了前端以外还了解什么其它技术么？你最最厉害的技能是什么？

5. 对前端开发工程师这个职位是怎么样理解的？它的前景会怎么样？

前端是最贴近用户的程序员，比后端、数据库、产品经理、运营、安全都近。

1、实现界面交互

2、提升用户体验

3、有了Node.js，前端可以实现服务端的一些事情

前端是最贴近用户的程序员，前端的能力就是能让产品从 90分进化到 100 分，甚至更好，

参与项目，快速高质量完成实现效果图，精确到1px；

与团队成员，UI设计，产品经理的沟通；

做好的页面结构，页面重构和用户体验；

处理hack，兼容、写出优美的代码格式；

针对服务器的优化、拥抱最新前端技术。