（干货）记前端工程师面试题，一块儿带你们理一理

时间 2019-11-05

标签干货前端工程师面试一块儿你们栏目快乐工作繁體版

原文原文链接

此文是上篇如何拿到大厂offer面试题|技术征文下，更新下剩下题目及答题思路javascript

1.请简单描述http协议的请求报文和响应报文的组成格式？

HTTP请求报文css

一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的通常格式。html

英文：前端

＜request-line＞

＜headers＞

＜blank line＞

＜request-body＞
java

1.请求头ios

请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。程序员

HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。web

2.请求头部面试

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：数据库

User-Agent：产生请求的浏览器类型。

Accept：客户端可识别的内容类型列表。

Host：请求的主机名，容许多个域名同处一个IP地址，即虚拟主机。

3.空行

最后一个请求头以后是一个空行，发送回车符和换行符，通知服务器如下再也不有请求头。

4.请求数据

请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于须要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

HTTP报文

HTTP响应也由三个部分组成，分别是：状态行、消息报头、响应正文。

以下所示，HTTP响应的格式与请求的格式十分相似：

英文：

＜status-line＞

＜headers＞

＜blank line＞

＜response-body＞

正如你所见，在响应中惟一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）经过提供一个状态码来讲明所请求的资源状况。

状态行格式以下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。

1xx：指示信息--表示请求已接收，继续处理。
2xx：成功--表示请求已被成功接收、理解、接受。
3xx：重定向--要完成请求必须进行更进一步的操做。
4xx：客户端错误--请求有语法错误或请求没法实现。
5xx：服务器端错误--服务器未能实现合法的请求。

常见状态代码、状态描述的说明以下。

200 OK：客户端请求成功。
400 Bad Request：客户端请求有语法错误，不能被服务器所理解。
401 Unauthorized：请求未经受权，这个状态代码必须和WWW-Authenticate报头域一块儿使用。
403 Forbidden：服务器收到请求，可是拒绝提供服务。
404 Not Found：请求资源不存在，举个例子：输入了错误的URL。
500 Internal Server Error：服务器发生不可预期的错误。
503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，举个例子：HTTP/1.1 200 OK（CRLF）。

详情能够参考该博客

2.用三种方式实现块框的垂直剧中效果，假设框的高度根据内容自适应

注意兼容性，autoprefixer能够处理前缀的兼容而已,对于不支持transform和flex的浏览器，若是要兼容该部分浏览器，请选择其余方式（笔者作的大可能是移动端，如下三种，除安卓4.3如下原生内核不支持外，并外见兼容性的bug,flex在X5内核，ios低版本内核中有些兼容性(如flex-wrap),需注意）。

第一种：flex

父元素设置如下属性
display:flex;
flex-direction:row //web 默认的值，rn默认column
align-items:center复制代码

第二种：absolute

父元素设置
position:relative
本元素
position:absolute;
top:50%;
transform:translateY(-50%);
复制代码

第三种：利用display:table-cell属性

display:table-cell;
vertical-alian:middle;复制代码

。。。还有不少

3.http中的状态码302表明的是什么意思

302重定向表示临时性转移(Temporarily Moved )，当一个网页URL须要短时间变化时使用。

顺便提一嘴301

301重定向/跳转通常，表示本网页永久性转移到另外一个地址。

301是永久性转移(Permanently Moved),SEO经常使用的招式，会把旧页面的PR等信息转移到新页面

301重定向与302重定向的区别

301重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向以后的网址。

302重定向是临时的重定向，搜索引擎会抓取新的内容而保留旧的网址。由于服务器返回302代码，搜索引擎认为新的网址只是暂时的。

4.cookie是什么，和session有什么区别

1，session 在服务器端，cookie 在客户端（浏览器）

2，session 默认被存在在服务器的一个文件里（不是内存）

3，session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，若是浏览

器禁用了 cookie ，同时 session 也会失效（可是能够经过其它方式实现，好比在 url 中传递

session_id）

4，session 能够放在文件、数据库、或内存中均可以。

5，用户验证这种场合通常会用 session

所以，维持一个会话的核心就是客户端的惟一标识，即 session id

5.有那些dom接口能够获取一个元素的尺寸（宽度和高度）

假设该元素id为box

1.第一种经过内联样式（注意：css声明中没有设置hieght和width的话是获取不到的,并且也不会根据box-sizing的值而返回不一样盒子模型的宽高）

var box = document.getElementById('box');
    var w = box.style.width;
    var h = box.style.height;复制代码

2.经过计算元素的大小（可是在ie状况下有一个问题，那就没写widht和height的css就返回auto，getComputedStyle在IE下若是设置了宽高为em这种单位,返回来的值依然是em,而不会是px）;

var style = window.getComputedStyle ? window.getComputedStyle(box,null) : null || box.currentStyle;
    var w = style.width;
    var h = style.height;复制代码

3.offsetHeight和offsetHeight

4.getBoundingClientRect（IE67的left、top会少2px,而且没有width、height属性，需兼容该部分浏览器的，那就不得不选择放弃了）DOMRect 对象包含了一组用于描述边框的只读属性——left、top、right和bottom，单位为像素。除了 width 和 height 外的属性都是相对于视口的左上角位置而言的

。。。

6.请描述dom事件的流程，即从触发到结束的整个过程

事件流包括三个阶段:事件捕获阶段、处于目标阶段和事件冒泡阶段。首先发生的是事件捕获，

为截获事件提供了机会。而后是实际的目标接收到事件。最后一个阶段是冒泡阶段，能够在这

个阶段对事件作出响应。单击<div>元素会按照以下图：

DOM 事件流中，实际的目标(<div>元素)在捕获阶段不会接收到事件。这意味着在捕获阶段，

12 事件从 document 到<html>再到<body>后就中止了。下一个阶段是“处于目标”阶段，因而

事件在<div> 上发生，并在事件处理(后面将会讨论这个概念)中被当作冒泡阶段的一部分。然

后，冒泡阶段发生，事件又传播回文档。

多数支持 DOM 事件流的浏览器都实现了一种特定的行为;即便“DOM2 级事件”规范明确要求

捕获阶段不会涉及事件目标，但 IE九、Safari、Chrome、Firefox 和 Opera 9.5 及更高版本都

会在捕获阶段触发事件对象上的事件。结果，就是有两个机会在目标对象上面操做事件。

以上是高程的内容。

7.请描述utf-8和unicode的区别

Unicode 是「字符集」
UTF-8 是「编码规则」

Unicode是一套复杂的字符编码标准，简单来讲就是将人类使用的每一个所谓字符与一个非负整数对应，而且保证不一样的字符对应的整数必定不一样。UTF-8是这个整数的编码方式，用1到4字节来表达一个整数。

关系：UTF-8是Unicode的实现方式之一，它规定了字符如何在计算机中存储、传输等。

8.讲一讲你在平常web开发中加载和交互体验上经常使用的优化策略

1. 减小HTTP请求数

这条策略基本上全部前端人都知道，并且也是最重要最有效的。都说要减小HTTP请求，那请求多了到底会怎么样呢？首先，每一个请求都是有成本的，既包含时间成本也包含资源成本。一个完整的请求都须要通过DNS寻址、与服务器创建链接、发送数据、等待服务器响应、接收数据这样一个“漫长”而复杂的过程。时间成本就是用户须要看到或者“感觉”到这个资源是必需要等待这个过程结束的，资源上因为每一个请求都须要携带数据，所以每一个请求都须要占用带宽。

另外，因为浏览器进行并发请求的请求数是有上限的，所以请求数多了之后，浏览器须要分批进行请求，所以会增长用户的等待时间，会给用户形成站点速度慢这样一个印象，即便可能用户能看到的第一屏的资源都已经请求完了，可是浏览器的进度条会一直存在。减小HTTP请求数的主要途径包括：

(1). 从设计实现层面简化页面

若是你的页面像百度首页同样简单，那么接下来的规则基本上都用不着了。保持页面简洁、减小资源的使用时最直接的。若是不是这样，你的页面须要华丽的皮肤，则继续阅读下面的内容。

(2). 合理设置HTTP缓存

缓存的力量是强大的，恰当的缓存设置能够大大的减小HTTP请求。以有啊首页为例，当浏览器没有缓存的时候访问一共会发出78个请求，共600多K 数据（如图1.1），而当第二次访问即浏览器已缓存以后访问则仅有10个请求，共20多K数据（如图1.2）。（这里须要说明的是，若是直接F5刷新页面的话效果是不同的，这种状况下请求数仍是同样，不过被缓存资源的请求服务器是304响应，只有Header没有Body，能够节省带宽）

怎样才算合理设置？原则很简单，能缓存越多越好，能缓存越久越好。例如，不多变化的图片资源能够直接经过HTTP Header中的Expires设置一个很长的过时头；变化不频繁而又可能会变的资源可使用Last-Modifed来作请求验证。尽量的让资源可以在缓存中待得更久。

(3). 资源合并与压缩

若是能够的话，尽量的将外部的脚本、样式进行合并，多个合为一个。另外，CSS、Javascript、Image均可以用相应的工具进行压缩，压缩后每每能省下很多空间。

(4). CSS Sprites

合并CSS图片，减小请求数的又一个好办法。

(5). Inline Images

使用data: URL scheme的方式将图片嵌入到页面或CSS中，若是不考虑资源管理上的问题的话，不失为一个好办法。若是是嵌入页面的话换来的是增大了页面的体积，并且没法利用浏览器缓存。使用在CSS中的图片则更为理想一些。

(6). Lazy Load Images

这条策略实际上并不必定能减小HTTP请求数，可是却能在某些条件下或者页面刚加载时减小HTTP请求数。对于图片而言，在页面刚加载的时候能够只加载第一屏，当用户继续日后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。有啊首页曾经的作法是在加载的时候把第一屏以后的图片地址缓存在Textarea标签中，待用户往下滚屏的时候才“惰性”加载。

2. 将外部脚本置底

前文有谈到，浏览器是能够并发请求的，这一特色使得其可以更快的加载资源，然而外链脚本在加载时却会阻塞其余资源，例如在脚本加载完成以前，它后面的图片、样式以及其余脚本都处于阻塞状态，直到脚本加载完成后才会开始加载。若是将脚本放在比较靠前的位置，则会影响整个页面的加载速度从而影响用户体验。解决这一问题的方法有不少，而最简单可依赖的方法就是将脚本尽量的日后挪，减小对并发下载的影响。

3. 异步执行inline脚本

inline脚本对性能的影响与外部脚本相比，是有过之而无不及。首页，与外部脚本同样，inline脚本在执行的时候同样会阻塞并发请求，除此之外，因为浏览器在页面处理方面是单线程的，当inline脚本在页面渲染以前执行时，页面的渲染工做则会被推迟。简而言之，inline脚本在执行的时候，页面处于空白状态。鉴于以上两点缘由，建议将执行时间较长的inline脚本异步执行，异步的方式有不少种，例如使用script元素的defer属性（存在兼容性问题和其余一些问题，例如不能使用document.write）、使用setTimeout，此外，在HTML5中引入了Web Workers的机制，偏偏能够解决此类问题。

4. Lazy Load Javascript

随着Javascript框架的流行，愈来愈多的站点也使用起了框架。不过，一个框架每每包括了不少的功能实现，这些功能并非每个页面都须要的，若是下载了不须要的脚本则算得上是一种资源浪费-既浪费了带宽又浪费了执行花费的时间。目前的作法大概有两种，一种是为那些流量特别大的页面专门定制一个专用的mini版框架，另外一种则是Lazy Load。YUI则使用了第二种方式，在YUI的实现中，最初只加载核心模块，其余模块能够等到须要使用的时候才加载。

5. 将CSS放在HEAD中

若是将CSS放在其余地方好比BODY中，则浏览器有可能还未下载和解析到CSS就已经开始渲染页面了，这就致使页面由无CSS状态跳转到CSS状态，用户体验比较糟糕。除此以外，有些浏览器会在CSS下载完成后才开始渲染页面，若是CSS放在靠下的位置则会致使浏览器将渲染时间推迟。

6. 减小没必要要的HTTP跳转

对于以目录形式访问的HTTP连接，不少人都会忽略连接最后是否带’/'，假如你的服务器对此是区别对待的话，那么你也须要注意，这其中极可能隐藏了301跳转，增长了多余请求。具体参见下图，其中第一个连接是以无’/'结尾的方式访问的，因而服务器有了一次跳转。

7. 避免重复的资源请求

这种状况主要是因为疏忽或页面由多个模块拼接而成，而后每一个模块中请求了一样的资源时，会致使资源的重复请求。出现的概率不大，可是仍是要注意排查。

。。。

9.什么是CSRF攻击，如何预防

CSRF全程 Cross Site Request Forgery, 跨站域请求伪造.CSRF是一种夹持用户在已经登录的web应用程序上执行非本意的操做的攻击方式。相比于XSS，CSRF是利用了系统对页面浏览器的信任，XSS则利用了系统对用户的信任。

防护CSRF攻击：

目前防护 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。

（1）验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在一般状况下，访问一个安全受限页面的请求来自于同一个网站，好比须要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登录 bank.example，而后经过点击页面上的按钮来触发转帐事件。这时，该转账请求的 Referer 值就会是转帐按钮所在的页面的 URL，一般是以 bank.example 域名开头的地址。而若是黑客要对银行网站实施 CSRF 攻击，他只能在他本身的网站构造请求，当用户经过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客本身的网站。所以，要防护 CSRF 攻击，银行网站只须要对于每个转帐请求验证其 Referer 值，若是是以 bank.example 开头的域名，则说明该请求是来自银行网站本身的请求，是合法的。若是 Referer 是其余网站的话，则有多是黑客的 CSRF 攻击，拒绝该请求。

这种方法的显而易见的好处就是简单易行，网站的普通开发人员不须要操心 CSRF 的漏洞，只须要在最后给全部安全敏感的请求统一增长一个拦截器来检查 Referer 的值就能够。特别是对于当前现有的系统，不须要改变当前系统的任何已有代码和逻辑，没有风险，很是便捷。

然而，这种方法并不是万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，可是每一个浏览器对于 Referer 的具体实现可能有差异，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来说，这样并不安全。事实上，对于某些浏览器，好比 IE6 或 FF2，目前已经有一些方法能够篡改 Referer 值。若是 bank.example 网站支持 IE6 浏览器，黑客彻底能够把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就能够经过验证，从而进行 CSRF 攻击。

即使是使用最新的浏览器，黑客没法篡改 Referer 值，这种方法仍然有问题。由于 Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们本身的隐私权，特别是有些组织担忧 Referer 值会把组织内网中的某些信息泄露到外网中。所以，用户本身能够设置浏览器使其在发送请求时再也不提供 Referer。当他们正常访问银行网站时，网站会由于请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。

（2）在请求地址中添加 token 并验证

CSRF 攻击之因此可以成功，是由于黑客能够彻底伪造用户的请求，该请求中全部的用户验证信息都是存在于 cookie 中，所以黑客能够在不知道这些验证信息的状况下直接利用用户本身的 cookie 来经过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，而且该信息不存在于 cookie 之中。能够在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端创建一个拦截器来验证这个 token，若是请求中没有 token 或者 token 内容不正确，则认为多是 CSRF 攻击而拒绝该请求。

这种方法要比检查 Referer 要安全一些，token 能够在用户登录后产生并放于 session 之中，而后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址以后，这样 URL 就变成 http://url?csrftoken=tokenvalue。而对于 POST 请求来讲，要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>，这样就把 token 以参数的形式加入请求了。可是，在一个网站中，能够接受请求的地方很是多，要对于每个请求都加上 token 是很麻烦的，而且很容易漏掉，一般使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中全部的 a 和 form 标签后加入 token。这样能够解决大部分的请求，可是对于在页面加载以后动态生成的 html 代码，这种方法就没有做用，还须要程序员在编码时手动添加 token。

该方法还有一个缺点是难以保证 token 自己的安全。特别是在一些论坛之类支持用户本身发表内容的网站，黑客能够在上面发布本身我的网站的地址。因为系统也会在这个地址后面加上 token，黑客能够在本身的网站上获得这个 token，并立刻就能够发动 CSRF 攻击。为了不这一点，系统能够在添加 token 的时候增长一个判断，若是这个连接是链到本身本站的，就在后面添加 token，若是是通向外网则不加。不过，即便这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也一样能够经过 Referer 来获得这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的缘由。

（3）在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不一样的是，这里并非把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。经过 XMLHttpRequest 这个类，能够一次性给全部该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，经过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担忧 token 会透过 Referer 泄露到其余网站中去。

然而这种方法的局限性很是大。XMLHttpRequest 请求一般用于 Ajax 方法中对于页面局部的异步刷新，并不是全部的请求都适合用这个类来发起，并且经过该类请求获得的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操做，给用户带来不便。另外，对于没有进行 CSRF 防御的遗留系统来讲，要采用这种方法来进行防御，要把全部请求都改成 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

10.script标签到defer和async属性有什么做用和区别

async属性，表示后续文档的加载和渲染与js脚本的加载和执行是并行进行的，即异步执行。

defer属性，加载后续文档的过程和js脚本的加载(此时仅加载不执行)是并行进行的(异步)，js脚本的执行须要等到文档全部元素解析完成以后，DOMContentLoaded事件触发执行以前。

区别

　　1.defer和async在网络加载过程是一致的，都是异步执行的；

　　2.二者的区别在于脚本加载完成以后什么时候执行，defer更符合大多数场景对应用脚本加载和执行的要求；

　　3.若是存在多个有defer属性的脚本，那么它们是按照加载顺序执行脚本的；而对于async，它的加载和执行是牢牢挨着的，不管声明顺序如何，只要加载完成就马上执行，它对于应用脚本用处不大，由于它彻底不考虑依赖。