美团前端常考面试题（必备）

跨域方案

很多种方法，但万变不离其宗，都是为了搞定同源策略。重用的有 jsonp、iframe、cors、img、HTML5 postMessage等等。其中用到 html 标签进行跨域的原理就是 html 不受同源策略影响。但只是接受 Get 的请求方式，这个得清楚。

延伸 1：img iframe script 来发送跨域请求有什么优缺点？

1. iframe

• 优点：跨域完毕之后DOM操作和互相之间的JavaScript调用都是没有问题的

• 缺点：1.若结果要以URL参数传递，这就意味着在结果数据量很大的时候需要分割传递，巨烦。2.还有一个是iframe本身带来的，母页面和iframe本身的交互本身就有安全性限制。

2. script

• 优点：可以直接返回json格式的数据，方便处理

• 缺点：只接受GET请求方式

3. 图片 ping

• 优点：可以访问任何url，一般用来进行点击追踪，做页面分析常用的方法

• 缺点：不能访问响应文本，只能监听是否响应

延伸 2：配合 webpack 进行反向代理？

webpack 在 devServer 选项里面提供了一个 proxy 的参数供开发人员进行反向代理

'/api': {  target: 'http://www.example.com', // your target host  changeOrigin: true, // needed for virtual hosted sites  pathRewrite: {    '^/api': ''  // rewrite path  }},

然后再配合 http-proxy-middleware 插件对 api 请求地址进行代理

const express = require('express');const proxy = require('http-proxy-middleware');// proxy api requestsconst exampleProxy = proxy(options); // 这里的 options 就是 webpack 里面的 proxy 选项对应的每个选项
// mount `exampleProxy` in web serverconst app = express();app.use('/api', exampleProxy);app.listen(3000);

然后再用 nginx 把允许跨域的源地址添加到报头里面即可

说到 nginx ，可以再谈谈 CORS 配置，大致如下

location / {  if ($request_method = 'OPTIONS') {    add_header 'Access-Control-Allow-Origin' '*';      add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';     add_header 'Access-Control-Allow-Credentials' 'true';    add_header 'Access-Control-Allow-Headers' 'DNT, X-Mx-ReqToken, Keep-Alive, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type';      add_header 'Access-Control-Max-Age' 86400;      add_header 'Content-Type' 'text/plain charset=UTF-8';      add_header 'Content-Length' 0;      return 200;    }}

createElement 过程

React.createElement()： 根据指定的第一个参数创建一个 React 元素

React.createElement(  type,  [props],  [...children])

• 第一个参数是必填，传入的是似 HTML 标签名称，eg: ul, li

• 第二个参数是选填，表示的是属性，eg: className

• 第三个参数是选填, 子节点，eg: 要显示的文本内容

//写法一：
var child1 = React.createElement('li', null, 'one');    var child2 = React.createElement('li', null, 'two');    var content = React.createElement('ul', { className: 'teststyle' }, child1, child2); // 第三个参数可以分开也可以写成一个数组      ReactDOM.render(          content,        document.getElementById('example')      );
//写法二：
var child1 = React.createElement('li', null, 'one');    var child2 = React.createElement('li', null, 'two');    var content = React.createElement('ul', { className: 'teststyle' }, [child1, child2]);      ReactDOM.render(          content,        document.getElementById('example')      );

TCP/IP 五层协议

TCP/IP五层协议和OSI的七层协议对应关系如下：

• **应用层 (application layer)**：直接为应用进程提供服务。应用层协议定义的是应用进程间通讯和交互的规则，不同的应用有着不同的应用层协议，如 HTTP 协议（万维网服务）、FTP 协议（文件传输）、SMTP 协议（电子邮件）、DNS（域名查询）等。

• **传输层 (transport layer)**：有时也译为运输层，它负责为两台主机中的进程提供通信服务。该层主要有以下两种协议：

• 传输控制协议 (Transmission Control Protocol，TCP)：提供面向连接的、可靠的数据传输服务，数据传输的基本单位是报文段（segment）；

• 用户数据报协议 (User Datagram Protocol，UDP)：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性，数据传输的基本单位是用户数据报。

• **网络层 (internet layer)**：有时也译为网际层，它负责为两台主机提供通信服务，并通过选择合适的路由将数据传递到目标主机。

• **数据链路层 (data link layer)**：负责将网络层交下来的 IP 数据报封装成帧，并在链路的两个相邻节点间传送帧，每一帧都包含数据和必要的控制信息（如同步信息、地址信息、差错控制等）。

• **物理层 (physical Layer)**：确保数据可以在各种物理媒介上进行传输，为数据的传输提供可靠的环境。

从上图中可以看出，TCP/IP模型比OSI模型更加简洁，它把应用层/表示层/会话层全部整合为了应用层。

在每一层都工作着不同的设备，比如我们常用的交换机就工作在数据链路层的，一般的路由器是工作在网络层的。 在每一层实现的协议也各不同，即每一层的服务也不同，下图列出了每层主要的传输协议：

同样，TCP/IP五层协议的通信方式也是对等通信：

事件机制

涉及面试题：事件的触发过程是怎么样的？知道什么是事件代理嘛？

1. 简介

事件流是一个事件沿着特定数据结构传播的过程。冒泡和捕获是事件流在DOM中两种不同的传播方法

事件流有三个阶段

• 事件捕获阶段

• 处于目标阶段

• 事件冒泡阶段

事件捕获

事件捕获（event capturing）：通俗的理解就是，当鼠标点击或者触发dom事件时，浏览器会从根节点开始由外到内进行事件传播，即点击了子元素，如果父元素通过事件捕获方式注册了对应的事件的话，会先触发父元素绑定的事件

事件冒泡

事件冒泡（dubbed bubbling）：与事件捕获恰恰相反，事件冒泡顺序是由内到外进行事件传播，直到根节点

无论是事件捕获还是事件冒泡，它们都有一个共同的行为，就是事件传播

2. 捕获和冒泡

<div id="div1">  <div id="div2"></div></div>
<script>    let div1 = document.getElementById('div1');    let div2 = document.getElementById('div2');
    div1.onClick = function(){        alert('1')    }
    div2.onClick = function(){        alert('2');    }
</script>

当点击 div2时，会弹出两个弹出框。在 ie8/9/10、chrome浏览器，会先弹出”2”再弹出“1”，这就是事件冒泡：事件从最底层的节点向上冒泡传播。事件捕获则跟事件冒泡相反

W3C 的标准是先捕获再冒泡， addEventListener的第三个参数决定把事件注册在捕获（true）还是冒泡(false)

3. 事件对象

4. 事件流阻止

在一些情况下需要阻止事件流的传播，阻止默认动作的发生

• event.preventDefault()：取消事件对象的默认动作以及继续传播。

• event.stopPropagation()/ event.cancelBubble = true：阻止事件冒泡。

事件的阻止在不同浏览器有不同处理

• 在IE下使用 event.returnValue= false，

• 在非IE下则使用 event.preventDefault()进行阻止

preventDefault 与 stopPropagation 的区别

• preventDefault告诉浏览器不用执行与事件相关联的默认动作（如表单提交）

• stopPropagation是停止事件继续冒泡，但是对 IE9 以下的浏览器无效

5. 事件注册

• 通常我们使用 addEventListener 注册事件，该函数的第三个参数可以是布尔值，也可以是对象。对于布尔值 useCapture 参数来说，该参数默认值为 false。useCapture 决定了注册的事件是捕获事件还是冒泡事件

• 一般来说，我们只希望事件只触发在目标上，这时候可以使用 stopPropagation 来阻止事件的进一步传播。通常我们认为 stopPropagation 是用来阻止事件冒泡的，其实该函数也可以阻止捕获事件。stopImmediatePropagation 同样也能实现阻止事件，但是还能阻止该事件目标执行别的注册事件

node.addEventListener('click',(event) =>{    event.stopImmediatePropagation()    console.log('冒泡')},false);// 点击 node 只会执行上面的函数，该函数不会执行node.addEventListener('click',(event) => {    console.log('捕获 ')},true)

6. 事件委托

• 在js中性能优化的其中一个主要思想是减少dom操作。

• 节省内存

• 不需要给子节点注销事件

假设有100个li，每个li有相同的点击事件。如果为每个Li都添加事件，则会造成dom访问次数过多，引起浏览器重绘与重排的次数过多，性能则会降低。 使用事件委托则可以解决这样的问题

原理

实现事件委托是利用了事件的冒泡原理实现的。当我们为最外层的节点添加点击事件，那么里面的ul、li、a的点击事件都会冒泡到最外层节点上，委托它代为执行事件

<ul id="ul">    <li>1</li>    <li>2</li>    <li>3</li></ul><script>  window.onload = function(){    var ulEle = document.getElementById('ul');    ul.onclick = function(ev){        //兼容IE        ev = ev || window.event;        var target = ev.target || ev.srcElement;
        if(target.nodeName.toLowerCase() == 'li'){            alert( target.innerHTML);        }
    }  }</script>

DNS 协议是什么

概念： DNS 是域名系统 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。它是一个由分层的 DNS 服务器组成的分布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。

作用： 将域名解析为 IP 地址，客户端向 DNS 服务器（DNS 服务器有自己的 IP 地址）发送域名查询请求，DNS 服务器告知客户机 Web 服务器的 IP 地址。

OSI 七层模型

ISO为了更好的使网络应用更为普及，推出了OSI参考模型。

（1）应用层

OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。

• 在客户端与服务器中经常会有数据的请求，这个时候就是会用到http(hyper text transfer protocol)(超文本传输协议)或者https.在后端设计数据接口时，我们常常使用到这个协议。

• FTP是文件传输协议，在开发过程中，个人并没有涉及到，但是我想，在一些资源网站，比如百度网盘``迅雷应该是基于此协议的。

• SMTP是simple mail transfer protocol（简单邮件传输协议）。在一个项目中，在用户邮箱验证码登录的功能时，使用到了这个协议。

（2）表示层

表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

在项目开发中，为了方便数据传输，可以使用base64对数据进行编解码。如果按功能来划分，base64应该是工作在表示层。

（3）会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

（4）传输层

传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP UDP就是在这一层。端口号既是这里的“端”。

（5）网络层

本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。

（6）数据链路层

将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用 MAC 地址)来访问介质,并进行差错检测。网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。

（7）物理层

实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。

OSI 七层模型通信特点：对等通信 对等通信，为了使数据分组从源传送到目的地，源端 OSI 模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信。在每一层通信过程中，使用本层自己协议进行通信。

参考 前端进阶面试题详细解答

HTTP 状态码

状态码的类别：

1. 2XX (Success 成功状态码)

状态码 2XX 表示请求被正常处理了。

（1）200 OK

200 OK 表示客户端发来的请求被服务器端正常处理了。

（2）204 No Content

该状态码表示客户端发送的请求已经在服务器端正常处理了，但是没有返回的内容，响应报文中不包含实体的主体部分。一般在只需要从客户端往服务器端发送信息，而服务器端不需要往客户端发送内容时使用。

（3）206 Partial Content

该状态码表示客户端进行了范围请求，而服务器端执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

2. 3XX (Redirection 重定向状态码)

3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

（1）301 Moved Permanently

永久重定向。 该状态码表示请求的资源已经被分配了新的 URI，以后应使用资源指定的 URI。新的 URI 会在 HTTP 响应头中的 Location 首部字段指定。若用户已经把原来的 URI 保存为书签，此时会按照 Location 中新的 URI 重新保存该书签。同时，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。

使用场景：

• 当我们想换个域名，旧的域名不再使用时，用户访问旧域名时用 301 就重定向到新的域名。其实也是告诉搜索引擎收录的域名需要对新的域名进行收录。

• 在搜索引擎的搜索结果中出现了不带 www 的域名，而带 www 的域名却没有收录，这个时候可以用 301 重定向来告诉搜索引擎我们目标的域名是哪一个。

（2）302 Found

临时重定向。 该状态码表示请求的资源被分配到了新的 URI，希望用户（本次）能使用新的 URI 访问资源。和 301 Moved Permanently 状态码相似，但是 302 代表的资源不是被永久重定向，只是临时性质的。也就是说已移动的资源对应的 URI 将来还有可能发生改变。若用户把 URI 保存成书签，但不会像 301 状态码出现时那样去更新书签，而是仍旧保留返回 302 状态码的页面对应的 URI。同时，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回 302 代码，搜索引擎认为新的网址只是暂时的。

使用场景：

• 当我们在做活动时，登录到首页自动重定向，进入活动页面。

• 未登陆的用户访问用户中心重定向到登录页面。

• 访问 404 页面重新定向到首页。

（3）303 See Other

该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。303 状态码和 302 Found 状态码有着相似的功能，但是 303 状态码明确表示客户端应当采用 GET 方法获取资源。

303 状态码通常作为 PUT 或 POST 操作的返回结果，它表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。

注意：

• 当 301、302、303 响应状态码返回时，几乎所有的浏览器都会把 POST 改成 GET，并删除请求报文内的主体，之后请求会再次自动发送。

• 301、302 标准是禁止将 POST 方法变成 GET 方法的，但实际大家都会这么做。

（4）304 Not Modified

浏览器缓存相关。 该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

带条件的请求（Http 条件请求）：使用 Get 方法 请求，请求报文中包含（if-match、if-none-match、if-modified-since、if-unmodified-since、if-range）中任意首部。

状态码 304 并不是一种错误，而是告诉客户端有缓存，直接使用缓存中的数据。返回页面的只有头部信息，是没有内容部分的，这样在一定程度上提高了网页的性能。

（5）307 Temporary Redirect

307 表示临时重定向。 该状态码与 302 Found 有着相同含义，尽管 302 标准禁止 POST 变成 GET，但是实际使用时还是这样做了。

307 会遵守浏览器标准，不会从 POST 变成 GET。但是对于处理请求的行为时，不同浏览器还是会出现不同的情况。规范要求浏览器继续向 Location 的地址 POST 内容。规范要求浏览器继续向 Location 的地址 POST 内容。

3. 4XX (Client Error 客户端错误状态码)

4XX 的响应结果表明客户端是发生错误的原因所在。

（1）400 Bad Request

该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。

（2）401 Unauthorized

该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。若之前已进行过一次请求，则表示用户认证失败

返回含有 401 的响应必须包含一个适用于被请求资源的 WWW-Authenticate 首部用以质询(challenge)用户信息。当浏览器初次接收到 401 响应，会弹出认证用的对话窗口。

以下情况会出现 401：

• 401.1 - 登录失败。

• 401.2 - 服务器配置导致登录失败。

• 401.3 - 由于 ACL 对资源的限制而未获得授权。

• 401.4 - 筛选器授权失败。

• 401.5 - ISAPI/CGI 应用程序授权失败。

• 401.7 - 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。

（3）403 Forbidden

该状态码表明请求资源的访问被服务器拒绝了，服务器端没有必要给出详细理由，但是可以在响应报文实体的主体中进行说明。进入该状态后，不能再继续进行验证。该访问是永久禁止的，并且与应用逻辑密切相关。

IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因：

• 403.1 - 执行访问被禁止。

• 403.2 - 读访问被禁止。

• 403.3 - 写访问被禁止。

• 403.4 - 要求 SSL。

• 403.5 - 要求 SSL 128。

• 403.6 - IP 地址被拒绝。

• 403.7 - 要求客户端证书。

• 403.8 - 站点访问被拒绝。

• 403.9 - 用户数过多。

• 403.10 - 配置无效。

• 403.11 - 密码更改。

• 403.12 - 拒绝访问映射表。

• 403.13 - 客户端证书被吊销。

• 403.14 - 拒绝目录列表。

• 403.15 - 超出客户端访问许可。

• 403.16 - 客户端证书不受信任或无效。

• 403.17 - 客户端证书已过期或尚未生效

• 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。

• 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。

• 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。

（4）404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。以下情况会出现 404：

• 404.0 -（无） – 没有找到文件或目录。

• 404.1 - 无法在所请求的端口上访问 Web 站点。

• 404.2 - Web 服务扩展锁定策略阻止本请求。

• 404.3 - MIME 映射策略阻止本请求。

（5）405 Method Not Allowed

该状态码表示客户端请求的方法虽然能被服务器识别，但是服务器禁止使用该方法。GET 和 HEAD 方法，服务器应该总是允许客户端进行访问。客户端可以通过 OPTIONS 方法（预检）来查看服务器允许的访问方法, 如下

Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE

4. 5XX (Server Error 服务器错误状态码)

5XX 的响应结果表明服务器本身发生错误.

（1）500 Internal Server Error

该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。

（2）502 Bad Gateway

该状态码表明扮演网关或代理角色的服务器，从上游服务器中接收到的响应是无效的。注意，502 错误通常不是客户端能够修复的，而是需要由途经的 Web 服务器或者代理服务器对其进行修复。以下情况会出现 502：

• 502.1 - CGI （通用网关接口）应用程序超时。

• 502.2 - CGI （通用网关接口）应用程序出错。

（3）503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter 首部字段再返回给客户端。

使用场景：

• 服务器停机维护时，主动用 503 响应请求；

• nginx 设置限速，超过限速，会返回 503。

（4）504 Gateway Timeout

该状态码表示网关或者代理的服务器无法在规定的时间内获得想要的响应。他是 HTTP 1.1 中新加入的。

使用场景：代码执行时间超时，或者发生了死循环。

5. 总结

（1）2XX 成功

• 200 OK，表示从客户端发来的请求在服务器端被正确处理

• 204 No content，表示请求成功，但响应报文不含实体的主体部分

• 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容

• 206 Partial Content，进行范围请求

（2）3XX 重定向

• 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL

• 302 found，临时性重定向，表示资源临时被分配了新的 URL

• 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源

• 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况

• 307 temporary redirect，临时重定向，和 302 含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

（3）4XX 客户端错误

• 400 bad request，请求报文存在语法错误

• 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息

• 403 forbidden，表示对请求资源的访问被服务器拒绝

• 404 not found，表示在服务器上没有找到请求的资源

（4）5XX 服务器错误

• 500 internal sever error，表示服务器端在执行请求时发生了错误

• 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能

• 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

This

不同情况的调用，this指向分别如何。顺带可以提一下 es6 中箭头函数没有 this, arguments, super 等，这些只依赖包含箭头函数最接近的函数

我们先来看几个函数调用的场景

function foo() {  console.log(this.a)}var a = 1foo()
const obj = {  a: 2,  foo: foo}obj.foo()
const c = new foo()

• 对于直接调用 foo 来说，不管 foo 函数被放在了什么地方，this 一定是window
  

• 对于 obj.foo() 来说，我们只需要记住，谁调用了函数，谁就是 this，所以在这个场景下 foo 函数中的 this 就是 obj 对象

• 对于 new 的方式来说，this 被永远绑定在了 c 上面，不会被任何方式改变 this
  

说完了以上几种情况，其实很多代码中的 this 应该就没什么问题了，下面让我们看看箭头函数中的 this

function a() {  return () => {    return () => {      console.log(this)    }  }}console.log(a()()())

• 首先箭头函数其实是没有 this 的，箭头函数中的 this 只取决包裹箭头函数的第一个普通函数的 this。在这个例子中，因为包裹箭头函数的第一个普通函数是 a，所以此时的 this 是 window。另外对箭头函数使用 bind这类函数是无效的。

• 最后种情况也就是 bind 这些改变上下文的 API 了，对于这些函数来说，this 取决于第一个参数，如果第一个参数为空，那么就是 window。

• 那么说到 bind，不知道大家是否考虑过，如果对一个函数进行多次 bind，那么上下文会是什么呢？

let a = {}let fn = function () { console.log(this) }fn.bind().bind(a)() // => ?

如果你认为输出结果是 a，那么你就错了，其实我们可以把上述代码转换成另一种形式

// fn.bind().bind(a) 等于let fn2 = function fn1() {  return function() {    return fn.apply()  }.apply(a)}fn2()

可以从上述代码中发现，不管我们给函数 bind 几次，fn 中的 this 永远由第一次 bind 决定，所以结果永远是 window

let a = { name: 'poetries' }function foo() {  console.log(this.name)}foo.bind(a)() // => 'poetries'

以上就是 this 的规则了，但是可能会发生多个规则同时出现的情况，这时候不同的规则之间会根据优先级最高的来决定 this 最终指向哪里。

首先，new 的方式优先级最高，接下来是 bind 这些函数，然后是 obj.foo() 这种调用方式，最后是 foo 这种调用方式，同时，箭头函数的 this 一旦被绑定，就不会再被任何方式所改变。

函数执行改变 this

• 由于 JS 的设计原理: 在函数中，可以引用运行环境中的变量。因此就需要一个机制来让我们可以在函数体内部获取当前的运行环境，这便是this。

因此要明白 this 指向，其实就是要搞清楚 函数的运行环境，说人话就是，谁调用了函数。例如

• obj.fn()，便是 obj 调用了函数，既函数中的 this === obj
  

• fn()，这里可以看成 window.fn()，因此 this === window
  

但这种机制并不完全能满足我们的业务需求，因此提供了三种方式可以手动修改 this 的指向:

• call: fn.call(target, 1, 2)
  

• apply: fn.apply(target, [1, 2])
  

• bind: fn.bind(target)(1,2)
  

TCP 的流量控制机制

一般来说，流量控制就是为了让发送方发送数据的速度不要太快，要让接收方来得及接收。TCP 采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。这里说的窗口大小其实就是每次传输的数据大小。

• 当一个连接建立时，连接的每一端分配一个缓冲区来保存输入的数据，并将缓冲区的大小发送给另一端。

• 当数据到达时，接收方发送确认，其中包含了自己剩余的缓冲区大小。（剩余的缓冲区空间的大小被称为窗口，指出窗口大小的通知称为窗口通告 。接收方在发送的每一确认中都含有一个窗口通告。）

• 如果接收方应用程序读数据的速度能够与数据到达的速度一样快，接收方将在每一确认中发送一个正的窗口通告。

• 如果发送方操作的速度快于接收方，接收到的数据最终将充满接收方的缓冲区，导致接收方通告一个零窗口 。发送方收到一个零窗口通告时，必须停止发送，直到接收方重新通告一个正的窗口。

TCP 和 UDP 的区别

模块化

js 中现在比较成熟的有四种模块加载方案：

• 第一种是 CommonJS 方案，它通过 require 来引入模块，通过 module.exports 定义模块的输出接口。这种模块加载方案是服务器端的解决方案，它是以同步的方式来引入模块的，因为在服务端文件都存储在本地磁盘，所以读取非常快，所以以同步的方式加载没有问题。但如果是在浏览器端，由于模块的加载是使用网络请求，因此使用异步加载的方式更加合适。

• 第二种是 AMD 方案，这种方案采用异步加载的方式来加载模块，模块的加载不影响后面语句的执行，所有依赖这个模块的语句都定义在一个回调函数里，等到加载完成后再执行回调函数。require.js 实现了 AMD 规范

• 第三种是 CMD 方案，这种方案和 AMD 方案都是为了解决异步模块加载的问题，sea.js 实现了 CMD 规范。它和 require.js 的区别在于模块定义时对依赖的处理不同和对依赖模块的执行时机的处理不同。

• 第四种方案是 ES6 提出的方案，使用 import 和 export 的形式来导入导出模块

在有 Babel 的情况下，我们可以直接使用 ES6的模块化

// file a.jsexport function a() {}export function b() {}// file b.jsexport default function() {}
import {a, b} from './a.js'import XXX from './b.js'

CommonJS

CommonJs 是 Node 独有的规范，浏览器中使用就需要用到 Browserify解析了。

// a.jsmodule.exports = {    a: 1}// orexports.a = 1
// b.jsvar module = require('./a.js')module.a // -> log 1

在上述代码中，module.exports 和 exports 很容易混淆，让我们来看看大致内部实现

var module = require('./a.js')module.a// 这里其实就是包装了一层立即执行函数，这样就不会污染全局变量了，// 重要的是 module 这里，module 是 Node 独有的一个变量module.exports = {    a: 1}// 基本实现var module = {  exports: {} // exports 就是个空对象}// 这个是为什么 exports 和 module.exports 用法相似的原因var exports = module.exportsvar load = function (module) {    // 导出的东西    var a = 1    module.exports = a    return module.exports};

再来说说 module.exports 和exports，用法其实是相似的，但是不能对 exports 直接赋值，不会有任何效果。

对于 CommonJS 和 ES6 中的模块化的两者区别是：

• 前者支持动态导入，也就是 require(${path}/xx.js)，后者目前不支持，但是已有提案,前者是同步导入，因为用于服务端，文件都在本地，同步导入即使卡住主线程影响也不大。

• 而后者是异步导入，因为用于浏览器，需要下载文件，如果也采用同步导入会对渲染有很大影响

• 前者在导出时都是值拷贝，就算导出的值变了，导入的值也不会改变，所以如果想更新值，必须重新导入一次。

• 但是后者采用实时绑定的方式，导入导出的值都指向同一个内存地址，所以导入值会跟随导出值变化

• 后者会编译成 require/exports 来执行的

AMD

AMD 是由 RequireJS 提出的

AMD 和 CMD 规范的区别？

• 第一个方面是在模块定义时对依赖的处理不同。AMD 推崇依赖前置，在定义模块的时候就要声明其依赖的模块。而 CMD 推崇就近依赖，只有在用到某个模块的时候再去 require。

• 第二个方面是对依赖模块的执行时机处理不同。首先 AMD 和 CMD 对于模块的加载方式都是异步加载，不过它们的区别在于模块的执行时机，AMD 在依赖模块加载完成后就直接执行依赖模块，依赖模块的执行顺序和我们书写的顺序不一定一致。而 CMD 在依赖模块加载完成后并不执行，只是下载而已，等到所有的依赖模块都加载好后，进入回调函数逻辑，遇到 require 语句的时候才执行对应的模块，这样模块的执行顺序就和我们书写的顺序保持一致了。

// CMDdefine(function(require, exports, module) {  var a = require("./a");  a.doSomething();  // 此处略去 100 行  var b = require("./b"); // 依赖可以就近书写  b.doSomething();  // ...});
// AMD 默认推荐define(["./a", "./b"], function(a, b) {  // 依赖必须一开始就写好  a.doSomething();  // 此处略去 100 行  b.doSomething();  // ...})

• AMD ：requirejs 在推广过程中对模块定义的规范化产出，提前执行，推崇依赖前置

• CMD ：seajs 在推广过程中对模块定义的规范化产出，延迟执行，推崇依赖就近

• CommonJs ：模块输出的是一个值的 copy，运行时加载，加载的是一个对象（module.exports 属性），该对象只有在脚本运行完才会生成

• ES6 Module ：模块输出的是一个值的引用，编译时输出接口，ES6模块不是对象，它对外接口只是一种静态定义，在代码静态解析阶段就会生成。

谈谈对模块化开发的理解

• 我对模块的理解是，一个模块是实现一个特定功能的一组方法。在最开始的时候，js 只实现一些简单的功能，所以并没有模块的概念，但随着程序越来越复杂，代码的模块化开发变得越来越重要。

• 由于函数具有独立作用域的特点，最原始的写法是使用函数来作为模块，几个函数作为一个模块，但是这种方式容易造成全局变量的污染，并且模块间没有联系。

• 后面提出了对象写法，通过将函数作为一个对象的方法来实现，这样解决了直接使用函数作为模块的一些缺点，但是这种办法会暴露所有的所有的模块成员，外部代码可以修改内部属性的值。

• 现在最常用的是立即执行函数的写法，通过利用闭包来实现模块私有作用域的建立，同时不会对全局作用域造成污染。

for...in 和 for...of 的区别

for…of 是 ES6 新增的遍历方式，允许遍历一个含有 iterator 接口的数据结构（数组、对象等）并且返回各项的值，和 ES3 中的 for…in 的区别如下

• for…of 遍历获取的是对象的键值，for…in 获取的是对象的键名；

• for… in 会遍历对象的整个原型链，性能非常差不推荐使用，而 for … of 只遍历当前对象不会遍历原型链；

• 对于数组的遍历，for…in 会返回数组中所有可枚举的属性(包括原型链上可枚举的属性)，for…of 只返回数组的下标对应的属性值；

总结： for...in 循环主要是为了遍历对象而生，不适用于遍历数组；for...of 循环可以用来遍历数组、类数组对象，字符串、Set、Map 以及 Generator 对象。

HTTP2 的头部压缩算法是怎样的？

HTTP2 的头部压缩是 HPACK 算法。在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，采用哈夫曼编码来压缩整数和字符串，可以达到 50%~90%的高压缩率。

具体来说:

• 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送；

• 首部表在 HTTP/2 的连接存续期内始终存在，由客户端和服务器共同渐进地更新；

• 每个新的首部键值对要么被追加到当前表的末尾，要么替换表中之前的值。

例如下图中的两个请求， 请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销。

数组能够调用的函数有那些？

• push

• pop

• splice

• slice

• shift

• unshift

• sort

• find

• findIndex

• map/filter/reduce 等函数式编程方法

• 还有一些原型链上的方法：toString/valudOf

原型链指向

p.__proto__  // Person.prototypePerson.prototype.__proto__  // Object.prototypep.__proto__.__proto__ //Object.prototypep.__proto__.constructor.prototype.__proto__ // Object.prototypePerson.prototype.constructor.prototype.__proto__ // Object.prototypep1.__proto__.constructor // PersonPerson.prototype.constructor  // Person

PWA 使用过吗？serviceWorker 的使用原理是啥？

渐进式网络应用（PWA）是谷歌在 2015 年底提出的概念。基本上算是 web 应用程序，但在外观和感觉上与原生app类似。支持PWA的网站可以提供脱机工作、推送通知和设备硬件访问等功能。

Service Worker是浏览器在后台独立于网页运行的脚本，它打开了通向不需要网页或用户交互的功能的大门。 现在，它们已包括如推送通知和后台同步等功能。 将来，Service Worker将会支持如定期同步或地理围栏等其他功能。 本教程讨论的核心功能是拦截和处理网络请求，包括通过程序来管理缓存中的响应。

代码输出结果

var F = function() {};Object.prototype.a = function() {  console.log('a');};Function.prototype.b = function() {  console.log('b');}var f = new F();f.a();f.b();F.a();F.b()

输出结果：

aUncaught TypeError: f.b is not a functionab

解析：

1. f 并不是 Function 的实例，因为它本来就不是构造函数，调用的是 Function 原型链上的相关属性和方法，只能访问到 Object 原型链。所以 f.a() 输出 a  ，而 f.b() 就报错了。

2. F 是个构造函数，而 F 是构造函数 Function 的一个实例。因为 F instanceof  Object === true，F instanceof Function === true，由此可以得出结论：F 是 Object 和 Function 两个的实例，即 F 能访问到 a， 也能访问到 b。所以 F.a() 输出 a ，F.b() 输出 b。

Proxy 可以实现什么功能？

在 Vue3.0 中通过 Proxy 来替换原本的 Object.defineProperty 来实现数据响应式。

Proxy 是 ES6 中新增的功能，它可以用来自定义对象中的操作。

let p = new Proxy(target, handler)

target 代表需要添加代理的对象，handler 用来自定义对象中的操作，比如可以用来自定义 set 或者 get 函数。

下面来通过 Proxy 来实现一个数据响应式：

let onWatch = (obj, setBind, getLogger) => {  let handler = {    get(target, property, receiver) {      getLogger(target, property)      return Reflect.get(target, property, receiver)    },    set(target, property, value, receiver) {      setBind(value, property)      return Reflect.set(target, property, value)    }  }  return new Proxy(obj, handler)}let obj = { a: 1 }let p = onWatch(  obj,  (v, property) => {    console.log(`监听到属性${property}改变为${v}`)  },  (target, property) => {    console.log(`'${property}' = ${target[property]}`)  })p.a = 2 // 监听到属性a改变p.a // 'a' = 2

在上述代码中，通过自定义 set 和 get 函数的方式，在原本的逻辑中插入了我们的函数逻辑，实现了在对对象任何属性进行读写时发出通知。

当然这是简单版的响应式实现，如果需要实现一个 Vue 中的响应式，需要在 get 中收集依赖，在 set 派发更新，之所以 Vue3.0 要使用 Proxy 替换原本的 API 原因在于 Proxy 无需一层层递归为每个属性添加代理，一次即可完成以上操作，性能上更好，并且原本的实现有一些数据更新不能监听到，但是 Proxy 可以完美监听到任何方式的数据改变，唯一缺陷就是浏览器的兼容性不好。

手写 bind、apply、call

// call
Function.prototype.call = function (context, ...args) {  context = context || window;
  const fnSymbol = Symbol("fn");  context[fnSymbol] = this;
  context[fnSymbol](...args);  delete context[fnSymbol];}

// apply
Function.prototype.apply = function (context, argsArr) {  context = context || window;
  const fnSymbol = Symbol("fn");  context[fnSymbol] = this;
  context[fnSymbol](...argsArr);  delete context[fnSymbol];}

// bind
Function.prototype.bind = function (context, ...args) {  context = context || window;  const fnSymbol = Symbol("fn");  context[fnSymbol] = this;
  return function (..._args) {    args = args.concat(_args);
    context[fnSymbol](...args);    delete context[fnSymbol];     }}

同样是重定向，307，303，302 的区别？

302 是 http1.0 的协议状态码，在 http1.1 版本的时候为了细化 302 状态码⼜出来了两个 303 和 307。 303 明确表示客户端应当采⽤get⽅法获取资源，他会把 POST 请求变为 GET 请求进⾏重定向。 307 会遵照浏览器标准，不会从 post 变为 get。