阿里前端二面常见面试题汇总

setTimeout、Promise、Async/Await 的区别

（1）setTimeout

console.log('script start')    //1. 打印 script startsetTimeout(function(){    console.log('settimeout')    // 4. 打印 settimeout})    // 2. 调用 setTimeout 函数，并定义其完成后执行的回调函数console.log('script end')    //3. 打印 script start// 输出顺序：script start->script end->settimeout

（2）Promise

Promise 本身是同步的立即执行函数， 当在 executor 中执行 resolve 或者 reject 的时候, 此时是异步操作， 会先执行 then/catch 等，当主栈完成后，才会去调用 resolve/reject 中存放的方法执行，打印 p 的时候，是打印的返回结果，一个 Promise 实例。

console.log('script start')let promise1 = new Promise(function (resolve) {    console.log('promise1')    resolve()    console.log('promise1 end')}).then(function () {    console.log('promise2')})setTimeout(function(){    console.log('settimeout')})console.log('script end')// 输出顺序: script start->promise1->promise1 end->script end->promise2->settimeout

当 JS 主线程执行到 Promise 对象时：

• promise1.then() 的回调就是一个 task

• promise1 是 resolved 或 rejected: 那这个 task 就会放入当前事件循环回合的 microtask queue

• promise1 是 pending: 这个 task 就会放入 事件循环的未来的某个(可能下一个)回合的 microtask queue 中

• setTimeout 的回调也是个 task ，它会被放入 macrotask queue 即使是 0ms 的情况

（3）async/await

async function async1(){   console.log('async1 start');    await async2();    console.log('async1 end')}async function async2(){    console.log('async2')}console.log('script start');async1();console.log('script end')// 输出顺序：script start->async1 start->async2->script end->async1 end

async 函数返回一个 Promise 对象，当函数执行的时候，一旦遇到 await 就会先返回，等到触发的异步操作完成，再执行函数体内后面的语句。可以理解为，是让出了线程，跳出了 async 函数体。

例如：

async function func1() {    return 1}console.log(func1())

func1 的运行结果其实就是一个 Promise 对象。因此也可以使用 then 来处理后续逻辑。

func1().then(res => {    console.log(res);  // 30})

await 的含义为等待，也就是 async 函数需要等待 await 后的函数执行完成并且有了返回结果（Promise 对象）之后，才能继续执行下面的代码。await 通过返回一个 Promise 对象来实现同步的效果。

如何解决跨越问题

（1）CORS

下面是 MDN 对于 CORS 的定义：

跨域资源共享(CORS) 是一种机制，它使用额外的 HTTP 头来告诉浏览器  让运行在一个 origin (domain)上的 Web 应用被准许访问来自不同源服务器上的指定的资源。当一个资源从与该资源本身所在的服务器不同的域、协议或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。

CORS 需要浏览器和服务器同时支持，整个 CORS 过程都是浏览器完成的，无需用户参与。因此实现 CORS 的关键就是服务器，只要服务器实现了 CORS 请求，就可以跨源通信了。

浏览器将 CORS 分为简单请求和非简单请求：

简单请求不会触发 CORS 预检请求。若该请求满足以下两个条件，就可以看作是简单请求：

1）请求方法是以下三种方法之一：

• HEAD

• GET

• POST

2）HTTP 的头信息不超出以下几种字段：

• Accept

• Accept-Language

• Content-Language

• Last-Event-ID

• Content-Type：只限于三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain

若不满足以上条件，就属于非简单请求了。

（1）简单请求过程：

对于简单请求，浏览器会直接发出 CORS 请求，它会在请求的头信息中增加一个 Orign 字段，该字段用来说明本次请求来自哪个源（协议+端口+域名），服务器会根据这个值来决定是否同意这次请求。如果 Orign 指定的域名在许可范围之内，服务器返回的响应就会多出以下信息头：

Access-Control-Allow-Origin: http://api.bob.com  // 和Orign一直Access-Control-Allow-Credentials: true   // 表示是否允许发送CookieAccess-Control-Expose-Headers: FooBar   // 指定返回其他字段的值Content-Type: text/html; charset=utf-8   // 表示文档类型

如果 Orign 指定的域名不在许可范围之内，服务器会返回一个正常的 HTTP 回应，浏览器发现没有上面的 Access-Control-Allow-Origin 头部信息，就知道出错了。这个错误无法通过状态码识别，因为返回的状态码可能是 200。

在简单请求中，在服务器内，至少需要设置字段：Access-Control-Allow-Origin

（2）非简单请求过程

非简单请求是对服务器有特殊要求的请求，比如请求方法为 DELETE 或者 PUT 等。非简单请求的 CORS 请求会在正式通信之前进行一次 HTTP 查询请求，称为预检请求。

浏览器会询问服务器，当前所在的网页是否在服务器允许访问的范围内，以及可以使用哪些 HTTP 请求方式和头信息字段，只有得到肯定的回复，才会进行正式的 HTTP 请求，否则就会报错。

预检请求使用的请求方法是 OPTIONS，表示这个请求是来询问的。他的头信息中的关键字段是 Orign，表示请求来自哪个源。除此之外，头信息中还包括两个字段：

• Access-Control-Request-Method：该字段是必须的，用来列出浏览器的 CORS 请求会用到哪些 HTTP 方法。

• Access-Control-Request-Headers： 该字段是一个逗号分隔的字符串，指定浏览器 CORS 请求会额外发送的头信息字段。

服务器在收到浏览器的预检请求之后，会根据头信息的三个字段来进行判断，如果返回的头信息在中有 Access-Control-Allow-Origin 这个字段就是允许跨域请求，如果没有，就是不同意这个预检请求，就会报错。

服务器回应的 CORS 的字段如下：

Access-Control-Allow-Origin: http://api.bob.com  // 允许跨域的源地址Access-Control-Allow-Methods: GET, POST, PUT // 服务器支持的所有跨域请求的方法Access-Control-Allow-Headers: X-Custom-Header  // 服务器支持的所有头信息字段Access-Control-Allow-Credentials: true   // 表示是否允许发送CookieAccess-Control-Max-Age: 1728000  // 用来指定本次预检请求的有效期，单位为秒

只要服务器通过了预检请求，在以后每次的 CORS 请求都会自带一个 Origin 头信息字段。服务器的回应，也都会有一个 Access-Control-Allow-Origin 头信息字段。

在非简单请求中，至少需要设置以下字段：

'Access-Control-Allow-Origin'  'Access-Control-Allow-Methods''Access-Control-Allow-Headers'

减少 OPTIONS 请求次数：

OPTIONS 请求次数过多就会损耗页面加载的性能，降低用户体验度。所以尽量要减少 OPTIONS 请求次数，可以后端在请求的返回头部添加：Access-Control-Max-Age：number。它表示预检请求的返回结果可以被缓存多久，单位是秒。该字段只对完全一样的 URL 的缓存设置生效，所以设置了缓存时间，在这个时间范围内，再次发送请求就不需要进行预检请求了。

CORS 中 Cookie 相关问题：

在 CORS 请求中，如果想要传递 Cookie，就要满足以下三个条件：

• 在请求中设置 withCredentials
  

默认情况下在跨域请求，浏览器是不带 cookie 的。但是我们可以通过设置 withCredentials 来进行传递 cookie.

// 原生 xml 的设置方式var xhr = new XMLHttpRequest();xhr.withCredentials = true;// axios 设置方式axios.defaults.withCredentials = true;

• Access-Control-Allow-Credentials 设置为 true

• Access-Control-Allow-Origin 设置为非 *
  

（2）JSONP

jsonp 的原理就是利用<script>标签没有跨域限制，通过<script>标签 src 属性，发送带有 callback 参数的 GET 请求，服务端将接口返回数据拼凑到 callback 函数中，返回给浏览器，浏览器解析执行，从而前端拿到 callback 函数返回的数据。1）原生 JS 实现：

<script>    var script = document.createElement('script');    script.type = 'text/javascript';    // 传参一个回调函数名给后端，方便后端返回时执行这个在前端定义的回调函数    script.src = 'http://www.domain2.com:8080/login?user=admin&callback=handleCallback';    document.head.appendChild(script);    // 回调执行函数    function handleCallback(res) {        alert(JSON.stringify(res));    } </script>

服务端返回如下（返回时即执行全局函数）：

handleCallback({"success": true, "user": "admin"})

2）Vue axios 实现：

this.$http = axios;this.$http.jsonp('http://www.domain2.com:8080/login', {    params: {},    jsonp: 'handleCallback'}).then((res) => {    console.log(res); })

后端 node.js 代码：

var querystring = require('querystring');var http = require('http');var server = http.createServer();server.on('request', function(req, res) {    var params = querystring.parse(req.url.split('?')[1]);    var fn = params.callback;    // jsonp返回设置    res.writeHead(200, { 'Content-Type': 'text/javascript' });    res.write(fn + '(' + JSON.stringify(params) + ')');    res.end();});server.listen('8080');console.log('Server is running at port 8080...');

JSONP 的缺点：

• 具有局限性， 仅支持 get 方法

• 不安全，可能会遭受 XSS 攻击

（3）postMessage 跨域

postMessage 是 HTML5 XMLHttpRequest Level 2 中的 API，且是为数不多可以跨域操作的 window 属性之一，它可用于解决以下方面的问题：

• 页面和其打开的新窗口的数据传递

• 多窗口之间消息传递

• 页面与嵌套的 iframe 消息传递

• 上面三个场景的跨域数据传递

用法：postMessage(data,origin)方法接受两个参数：

• data： html5 规范支持任意基本类型或可复制的对象，但部分浏览器只支持字符串，所以传参时最好用 JSON.stringify()序列化。

• origin： 协议+主机+端口号，也可以设置为"*"，表示可以传递给任意窗口，如果要指定和当前窗口同源的话设置为"/"。

1）a.html：(domain1.com/a.html)

<iframe id="iframe" src="http://www.domain2.com/b.html" style="display:none;"></iframe><script>           var iframe = document.getElementById('iframe');    iframe.onload = function() {        var data = {            name: 'aym'        };        // 向domain2传送跨域数据        iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.domain2.com');    };    // 接受domain2返回数据    window.addEventListener('message', function(e) {        alert('data from domain2 ---> ' + e.data);    }, false);</script>

2）b.html：(domain2.com/b.html)

<script>    // 接收domain1的数据    window.addEventListener('message', function(e) {        alert('data from domain1 ---> ' + e.data);        var data = JSON.parse(e.data);        if (data) {            data.number = 16;            // 处理后再发回domain1            window.parent.postMessage(JSON.stringify(data), 'http://www.domain1.com');        }    }, false);</script>

（4）nginx 代理跨域

nginx 代理跨域，实质和 CORS 跨域原理一样，通过配置文件设置请求响应头 Access-Control-Allow-Origin…等字段。

1）nginx 配置解决 iconfont 跨域浏览器跨域访问 js、css、img 等常规静态资源被同源策略许可，但 iconfont 字体文件(eot|otf|ttf|woff|svg)例外，此时可在 nginx 的静态资源服务器中加入以下配置。

location / {  add_header Access-Control-Allow-Origin *;}

2）nginx 反向代理接口跨域跨域问题：同源策略仅是针对浏览器的安全策略。服务器端调用 HTTP 接口只是使用 HTTP 协议，不需要同源策略，也就不存在跨域问题。实现思路：通过 Nginx 配置一个代理服务器域名与 domain1 相同，端口不同）做跳板机，反向代理访问 domain2 接口，并且可以顺便修改 cookie 中 domain 信息，方便当前域 cookie 写入，实现跨域访问。

nginx 具体配置：

#proxy服务器server {    listen       81;    server_name  www.domain1.com;    location / {        proxy_pass   http://www.domain2.com:8080;  #反向代理        proxy_cookie_domain www.domain2.com www.domain1.com; #修改cookie里域名        index  index.html index.htm;        # 当用webpack-dev-server等中间件代理接口访问nignx时，此时无浏览器参与，故没有同源限制，下面的跨域配置可不启用        add_header Access-Control-Allow-Origin http://www.domain1.com;  #当前端只跨域不带cookie时，可为*        add_header Access-Control-Allow-Credentials true;    }}

（5）nodejs 中间件代理跨域

node 中间件实现跨域代理，原理大致与 nginx 相同，都是通过启一个代理服务器，实现数据的转发，也可以通过设置 cookieDomainRewrite 参数修改响应头中 cookie 中域名，实现当前域的 cookie 写入，方便接口登录认证。

1）非 vue 框架的跨域 使用 node + express + http-proxy-middleware 搭建一个 proxy 服务器。

• 前端代码：

var xhr = new XMLHttpRequest();// 前端开关：浏览器是否读写cookiexhr.withCredentials = true;// 访问http-proxy-middleware代理服务器xhr.open('get', 'http://www.domain1.com:3000/login?user=admin', true);xhr.send();

• 中间件服务器代码：

var express = require('express');var proxy = require('http-proxy-middleware');var app = express();app.use('/', proxy({    // 代理跨域目标接口    target: 'http://www.domain2.com:8080',    changeOrigin: true,    // 修改响应头信息，实现跨域并允许带cookie    onProxyRes: function(proxyRes, req, res) {        res.header('Access-Control-Allow-Origin', 'http://www.domain1.com');        res.header('Access-Control-Allow-Credentials', 'true');    },    // 修改响应信息中的cookie域名    cookieDomainRewrite: 'www.domain1.com'  // 可以为false，表示不修改}));app.listen(3000);console.log('Proxy server is listen at port 3000...');

2）vue 框架的跨域

node + vue + webpack + webpack-dev-server 搭建的项目，跨域请求接口，直接修改 webpack.config.js 配置。开发环境下，vue 渲染服务和接口代理服务都是 webpack-dev-server 同一个，所以页面与代理接口之间不再跨域。

webpack.config.js 部分配置：

module.exports = {    entry: {},    module: {},    ...    devServer: {        historyApiFallback: true,        proxy: [{            context: '/login',            target: 'http://www.domain2.com:8080',  // 代理跨域目标接口            changeOrigin: true,            secure: false,  // 当代理某些https服务报错时用            cookieDomainRewrite: 'www.domain1.com'  // 可以为false，表示不修改        }],        noInfo: true    }}

（6）document.domain + iframe 跨域

此方案仅限主域相同，子域不同的跨域应用场景。实现原理：两个页面都通过 js 强制设置 document.domain 为基础主域，就实现了同域。1）父窗口：(domain.com/a.html)

<iframe id="iframe" src="http://child.domain.com/b.html"></iframe><script>    document.domain = 'domain.com';    var user = 'admin';</script>

1）子窗口：(child.domain.com/a.html)

<script>    document.domain = 'domain.com';    // 获取父窗口中变量    console.log('get js data from parent ---> ' + window.parent.user);</script>

（7）location.hash + iframe 跨域

实现原理：a 欲与 b 跨域相互通信，通过中间页 c 来实现。 三个页面，不同域之间利用 iframe 的 location.hash 传值，相同域之间直接 js 访问来通信。

具体实现：A 域：a.html -> B 域：b.html -> A 域：c.html，a 与 b 不同域只能通过 hash 值单向通信，b 与 c 也不同域也只能单向通信，但 c 与 a 同域，所以 c 可通过 parent.parent 访问 a 页面所有对象。

1）a.html：(domain1.com/a.html)

<iframe id="iframe" src="http://www.domain2.com/b.html" style="display:none;"></iframe><script>    var iframe = document.getElementById('iframe');    // 向b.html传hash值    setTimeout(function() {        iframe.src = iframe.src + '#user=admin';    }, 1000);        // 开放给同域c.html的回调方法    function onCallback(res) {        alert('data from c.html ---> ' + res);    }</script>

2）b.html：(.domain2.com/b.html)

<iframe id="iframe" src="http://www.domain1.com/c.html" style="display:none;"></iframe><script>    var iframe = document.getElementById('iframe');    // 监听a.html传来的hash值，再传给c.html    window.onhashchange = function () {        iframe.src = iframe.src + location.hash;    };</script>

<script>    // 监听b.html传来的hash值    window.onhashchange = function () {        // 再通过操作同域a.html的js回调，将结果传回        window.parent.parent.onCallback('hello: ' + location.hash.replace('#user=', ''));    };</script>

（8）window.name + iframe 跨域

window.name 属性的独特之处：name 值在不同的页面（甚至不同域名）加载后依旧存在，并且可以支持非常长的 name 值（2MB）。

1）a.html：(domain1.com/a.html)

var proxy = function(url, callback) {    var state = 0;    var iframe = document.createElement('iframe');    // 加载跨域页面    iframe.src = url;    // onload事件会触发2次，第1次加载跨域页，并留存数据于window.name    iframe.onload = function() {        if (state === 1) {            // 第2次onload(同域proxy页)成功后，读取同域window.name中数据            callback(iframe.contentWindow.name);            destoryFrame();        } else if (state === 0) {            // 第1次onload(跨域页)成功后，切换到同域代理页面            iframe.contentWindow.location = 'http://www.domain1.com/proxy.html';            state = 1;        }    };    document.body.appendChild(iframe);    // 获取数据以后销毁这个iframe，释放内存；这也保证了安全（不被其他域frame js访问）    function destoryFrame() {        iframe.contentWindow.document.write('');        iframe.contentWindow.close();        document.body.removeChild(iframe);    }};// 请求跨域b页面数据proxy('http://www.domain2.com/b.html', function(data){    alert(data);});

2）proxy.html：(domain1.com/proxy.html)

中间代理页，与 a.html 同域，内容为空即可。3）b.html：(domain2.com/b.html)

<script>        window.name = 'This is domain2 data!';</script>

通过 iframe 的 src 属性由外域转向本地域，跨域数据即由 iframe 的 window.name 从外域传递到本地域。这个就巧妙地绕过了浏览器的跨域访问限制，但同时它又是安全操作。

（9）WebSocket 协议跨域

WebSocket protocol 是 HTML5 一种新的协议。它实现了浏览器与服务器全双工通信，同时允许跨域通讯，是 server push 技术的一种很好的实现。

原生 WebSocket API 使用起来不太方便，我们使用 Socket.io，它很好地封装了 webSocket 接口，提供了更简单、灵活的接口，也对不支持 webSocket 的浏览器提供了向下兼容。

1）前端代码：

<div>user input：<input type="text"></div><script src="https://cdn.bootcss.com/socket.io/2.2.0/socket.io.js"></script><script>var socket = io('http://www.domain2.com:8080');// 连接成功处理socket.on('connect', function() {    // 监听服务端消息    socket.on('message', function(msg) {        console.log('data from server: ---> ' + msg);     });    // 监听服务端关闭    socket.on('disconnect', function() {         console.log('Server socket has closed.');     });});document.getElementsByTagName('input')[0].onblur = function() {    socket.send(this.value);};</script>

2）Nodejs socket 后台：

var http = require('http');var socket = require('socket.io');// 启http服务var server = http.createServer(function(req, res) {    res.writeHead(200, {        'Content-type': 'text/html'    });    res.end();});server.listen('8080');console.log('Server is running at port 8080...');// 监听socket连接socket.listen(server).on('connection', function(client) {    // 接收信息    client.on('message', function(msg) {        client.send('hello：' + msg);        console.log('data from client: ---> ' + msg);    });    // 断开处理    client.on('disconnect', function() {        console.log('Client socket has closed.');     });});

代码输出结果

function Person(name) {    this.name = name}var p2 = new Person('king');console.log(p2.__proto__) //Person.prototypeconsole.log(p2.__proto__.__proto__) //Object.prototypeconsole.log(p2.__proto__.__proto__.__proto__) // nullconsole.log(p2.__proto__.__proto__.__proto__.__proto__)//null后面没有了，报错console.log(p2.__proto__.__proto__.__proto__.__proto__.__proto__)//null后面没有了，报错console.log(p2.constructor)//Personconsole.log(p2.prototype)//undefined p2是实例，没有prototype属性console.log(Person.constructor)//Function 一个空函数console.log(Person.prototype)//打印出Person.prototype这个对象里所有的方法和属性console.log(Person.prototype.constructor)//Personconsole.log(Person.prototype.__proto__)// Object.prototypeconsole.log(Person.__proto__) //Function.prototypeconsole.log(Function.prototype.__proto__)//Object.prototypeconsole.log(Function.__proto__)//Function.prototypeconsole.log(Object.__proto__)//Function.prototypeconsole.log(Object.prototype.__proto__)//null

这道义题目考察原型、原型链的基础，记住就可以了。

正向代理和反向代理的区别

• 正向代理：

客户端想获得一个服务器的数据，但是因为种种原因无法直接获取。于是客户端设置了一个代理服务器，并且指定目标服务器，之后代理服务器向目标服务器转交请求并将获得的内容发送给客户端。这样本质上起到了对真实服务器隐藏真实客户端的目的。实现正向代理需要修改客户端，比如修改浏览器配置。

• 反向代理：

服务器为了能够将工作负载分不到多个服务器来提高网站性能 (负载均衡)等目的，当其受到请求后，会首先根据转发规则来确定请求应该被转发到哪个服务器上，然后将请求转发到对应的真实服务器上。这样本质上起到了对客户端隐藏真实服务器的作用。一般使用反向代理后，需要通过修改 DNS 让域名解析到代理服务器 IP，这时浏览器无法察觉到真正服务器的存在，当然也就不需要修改配置了。

正向代理和反向代理的结构是一样的，都是 client-proxy-server 的结构，它们主要的区别就在于中间这个 proxy 是哪一方设置的。在正向代理中，proxy 是 client 设置的，用来隐藏 client；而在反向代理中，proxy 是 server 设置的，用来隐藏 server。

什么是中间人攻击？如何防范中间人攻击？

中间⼈ (Man-in-the-middle attack, MITM) 是指攻击者与通讯的两端分别创建独⽴的联系, 并交换其所收到的数据, 使通讯的两端认为他们正在通过⼀个私密的连接与对⽅直接对话, 但事实上整个会话都被攻击者完全控制。在中间⼈攻击中，攻击者可以拦截通讯双⽅的通话并插⼊新的内容。

攻击过程如下:

• 客户端发送请求到服务端，请求被中间⼈截获

• 服务器向客户端发送公钥

• 中间⼈截获公钥，保留在⾃⼰⼿上。然后⾃⼰⽣成⼀个伪造的公钥，发给客户端

• 客户端收到伪造的公钥后，⽣成加密 hash 值发给服务器

• 中间⼈获得加密 hash 值，⽤⾃⼰的私钥解密获得真秘钥,同时⽣成假的加密 hash 值，发给服务器

• 服务器⽤私钥解密获得假密钥,然后加密数据传输给客户端

浏览器渲染进程的线程有哪些

浏览器的渲染进程的线程总共有五种： （1）GUI 渲染线程 负责渲染浏览器页面，解析 HTML、CSS，构建 DOM 树、构建 CSSOM 树、构建渲染树和绘制页面；当界面需要重绘或由于某种操作引发回流时，该线程就会执行。

注意：GUI 渲染线程和 JS 引擎线程是互斥的，当 JS 引擎执行时 GUI 线程会被挂起，GUI 更新会被保存在一个队列中等到 JS 引擎空闲时立即被执行。

（2）JS 引擎线程 JS 引擎线程也称为 JS 内核，负责处理 Javascript 脚本程序，解析 Javascript 脚本，运行代码；JS 引擎线程一直等待着任务队列中任务的到来，然后加以处理，一个 Tab 页中无论什么时候都只有一个 JS 引擎线程在运行 JS 程序；

注意：GUI 渲染线程与 JS 引擎线程的互斥关系，所以如果 JS 执行的时间过长，会造成页面的渲染不连贯，导致页面渲染加载阻塞。

（3）时间触发线程 时间触发线程属于浏览器而不是 JS 引擎，用来控制事件循环；当 JS 引擎执行代码块如 setTimeOut 时（也可是来自浏览器内核的其他线程,如鼠标点击、AJAX 异步请求等），会将对应任务添加到事件触发线程中；当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待 JS 引擎的处理；

注意：由于 JS 的单线程关系，所以这些待处理队列中的事件都得排队等待 JS 引擎处理（当 JS 引擎空闲时才会去执行）；

（4）定时器触发进程 定时器触发进程即 setInterval 与 setTimeout 所在线程；浏览器定时计数器并不是由 JS 引擎计数的，因为 JS 引擎是单线程的，如果处于阻塞线程状态就会影响记计时的准确性；因此使用单独线程来计时并触发定时器，计时完毕后，添加到事件队列中，等待 JS 引擎空闲后执行，所以定时器中的任务在设定的时间点不一定能够准时执行，定时器只是在指定时间点将任务添加到事件队列中；

注意：W3C 在 HTML 标准中规定，定时器的定时时间不能小于 4ms，如果是小于 4ms，则默认为 4ms。

（5）异步 http 请求线程

• XMLHttpRequest 连接后通过浏览器新开一个线程请求；

• 检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将回调函数放入事件队列中，等待 JS 引擎空闲后执行；

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

浏览器资源缓存的位置有哪些？

资源缓存的位置一共有 3 种，按优先级从高到低分别是：

1. Service Worker：Service Worker 运行在 JavaScript 主线程之外，虽然由于脱离了浏览器窗体无法直接访问 DOM，但是它可以完成离线缓存、消息推送、网络代理等功能。它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。当 Service Worker 没有命中缓存的时候，需要去调用 fetch 函数获取 数据。也就是说，如果没有在 Service Worker 命中缓存，会根据缓存查找优先级去查找数据。但是不管是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示是从 Service Worker 中获取的内容。

2. Memory Cache： Memory Cache 就是内存缓存，它的效率最快，但是内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。

3. Disk Cache： Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。

Disk Cache： Push Cache 是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。并且缓存时间也很短暂，只在会话（Session）中存在，一旦会话结束就被释放。其具有以下特点：

• 所有的资源都能被推送，但是 Edge 和 Safari 浏览器兼容性不怎么好

• 可以推送 no-cache 和 no-store 的资源

• 一旦连接被关闭，Push Cache 就被释放

• 多个页面可以使用相同的 HTTP/2 连接，也就是说能使用同样的缓存

• Push Cache 中的缓存只能被使用一次

• 浏览器可以拒绝接受已经存在的资源推送

• 可以给其他域名推送资源​

如何根据设计稿进行移动端适配？

移动端适配主要有两个维度：

• 适配不同像素密度， 针对不同的像素密度，使用 CSS 媒体查询，选择不同精度的图片，以保证图片不会失真；

• 适配不同屏幕大小， 由于不同的屏幕有着不同的逻辑像素大小，所以如果直接使用 px 作为开发单位，会使得开发的页面在某一款手机上可以准确显示，但是在另一款手机上就会失真。为了适配不同屏幕的大小，应按照比例来还原设计稿的内容。

为了能让页面的尺寸自适应，可以使用 rem，em，vw，vh 等相对单位。

对媒体查询的理解？

媒体查询由⼀个可选的媒体类型和零个或多个使⽤媒体功能的限制了样式表范围的表达式组成，例如宽度、⾼度和颜⾊。媒体查询，添加⾃CSS3，允许内容的呈现针对⼀个特定范围的输出设备⽽进⾏裁剪，⽽不必改变内容本身，适合 web⽹⻚应对不同型号的设备⽽做出对应的响应适配。

媒体查询包含⼀个可选的媒体类型和满⾜CSS3 规范的条件下，包含零个或多个表达式，这些表达式描述了媒体特征，最终会被解析为 true 或 false。如果媒体查询中指定的媒体类型匹配展示⽂档所使⽤的设备类型，并且所有的表达式的值都是 true，那么该媒体查询的结果为 true。那么媒体查询内的样式将会⽣效。

<!-- link元素中的CSS媒体查询 --> <link rel="stylesheet" media="(max-width: 800px)" href="example.css" /> <!-- 样式表中的CSS媒体查询 --> <style> @media (max-width: 600px) {   .facet_sidebar {     display: none;   } }</style>

简单来说，使用 @media 查询，可以针对不同的媒体类型定义不同的样式。@media 可以针对不同的屏幕尺寸设置不同的样式，特别是需要设置设计响应式的页面，@media 是非常有用的。当重置浏览器大小的过程中，页面也会根据浏览器的宽度和高度重新渲染页面。

谈一谈你对 HTTP/2 理解

首先补充一下，http 和 https 的区别，相比于 http,https 是基于 ssl 加密的 http 协议

简要概括:http2.0 是基于 1999 年发布的 http1.0 之后的首次更新

• 提升访问速度 (可以对于，请求资源所需时间更少，访问速度更快，相比 http1.0)

• 允许多路复用 :多路复用允许同时通过单一的 HTTP/2 连接发送多重请求-响应信息。改 善了:在 http1.1 中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限 制(连接数量)，超过限制会被阻塞

• 二进制分帧 :HTTP2.0 会将所有的传输信息分割为更小的信息或者帧，并对他们进行二 进制编码

• 首部压缩

• 服务器端推送

头部压缩

HTTP 1.1 版本会出现 User-Agent、Cookie、Accept、Server、Range 等字段可能会占用几百甚至几千字节，而 Body 却经常只有几十字节，所以导致头部偏重。

HTTP 2.0 使用 HPACK 算法进行压缩。

多路复用

• HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8 个的 TCP 链接请求限制。

HTTP2 中：

• 同域名下所有通信都在单个连接上完成。

• 单个连接可以承载任意数量的双向数据流。

• 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装，也就是Stream ID，流标识符，有了它，接收方就能从乱序的二进制帧中选择 ID 相同的帧，按照顺序组装成请求/响应报文。

服务器推送

浏览器发送一个请求，服务器主动向浏览器推送与这个请求相关的资源，这样浏览器就不用发起后续请求。

相比较 http/1.1 的优势👇

• 推送资源可以由不同页面共享

• 服务器可以按照优先级推送资源

• 客户端可以缓存推送的资源

• 客户端可以拒收推送过来的资源

二进制分帧

之前是明文传输，不方便计算机解析，对于回车换行符来说到底是内容还是分隔符，都需要内部状态机去识别，这样子效率低，HTTP/2 采用二进制格式，全部传输 01 串，便于机器解码。

这样子一个报文格式就被拆分为一个个二进制帧，用 Headers 帧存放头部字段，Data 帧存放请求体数据。这样子的话，就是一堆乱序的二进制帧，它们不存在先后关系，因此不需要排队等待，解决了 HTTP 队头阻塞问题。

在客户端与服务器之间，双方都可以互相发送二进制帧，这样子 双向传输的序列 ，称为流，所以 HTTP/2 中以流来表示一个 TCP 连接上进行多个数据帧的通信，这就是多路复用概念。

那乱序的二进制帧，是如何组装成对于的报文呢？

• 所谓的乱序，值的是不同 ID 的 Stream 是乱序的，对于同一个 Stream ID 的帧是按顺序传输的。

• 接收方收到二进制帧后，将相同的 Stream ID 组装成完整的请求报文和响应报文。

• 二进制帧中有一些字段，控制着优先级和流量控制等功能，这样子的话，就可以设置数据帧的优先级，让服务器处理重要资源，优化用户体验。

HTTP2 的缺点

• TCP 以及 TCP+TLS 建立连接的延时,HTTP/2 使用 TCP 协议来传输的，而如果使用 HTTPS 的话，还需要使用 TLS 协议进行安全传输，而使用 TLS 也需要一个握手过程,在传输数据之前，导致我们需要花掉 3～4 个 RTT。

• TCP 的队头阻塞并没有彻底解决。在 HTTP/2 中，多个请求是跑在一个 TCP 管道中的。但当 HTTP/2 出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该 TCP 连接中的所有请求。

常见的浏览器内核比较

• Trident： 这种浏览器内核是 IE 浏览器用的内核，因为在早期 IE 占有大量的市场份额，所以这种内核比较流行，以前有很多网页也是根据这个内核的标准来编写的，但是实际上这个内核对真正的网页标准支持不是很好。但是由于 IE 的高市场占有率，微软也很长时间没有更新 Trident 内核，就导致了 Trident 内核和 W3C 标准脱节。还有就是 Trident 内核的大量 Bug 等安全问题没有得到解决，加上一些专家学者公开自己认为 IE 浏览器不安全的观点，使很多用户开始转向其他浏览器。

• Gecko： 这是 Firefox 和 Flock 所采用的内核，这个内核的优点就是功能强大、丰富，可以支持很多复杂网页效果和浏览器扩展接口，但是代价是也显而易见就是要消耗很多的资源，比如内存。

• Presto： Opera 曾经采用的就是 Presto 内核，Presto 内核被称为公认的浏览网页速度最快的内核，这得益于它在开发时的天生优势，在处理 JS 脚本等脚本语言时，会比其他的内核快 3 倍左右，缺点就是为了达到很快的速度而丢掉了一部分网页兼容性。

• Webkit： Webkit 是 Safari 采用的内核，它的优点就是网页浏览速度较快，虽然不及 Presto 但是也胜于 Gecko 和 Trident，缺点是对于网页代码的容错性不高，也就是说对网页代码的兼容性较低，会使一些编写不标准的网页无法正确显示。WebKit 前身是 KDE 小组的 KHTML 引擎，可以说 WebKit 是 KHTML 的一个开源的分支。

• Blink： 谷歌在 Chromium Blog 上发表博客，称将与苹果的开源浏览器核心 Webkit 分道扬镳，在 Chromium 项目中研发 Blink 渲染引擎（即浏览器核心），内置于 Chrome 浏览器之中。其实 Blink 引擎就是 Webkit 的一个分支，就像 webkit 是 KHTML 的分支一样。Blink 引擎现在是谷歌公司与 Opera Software 共同研发，上面提到过的，Opera 弃用了自己的 Presto 内核，加入 Google 阵营，跟随谷歌一起研发 Blink。

对 CSS 工程化的理解

CSS 工程化是为了解决以下问题：

1. 宏观设计：CSS 代码如何组织、如何拆分、模块结构怎样设计？

2. 编码优化：怎样写出更好的 CSS？

3. 构建：如何处理我的 CSS，才能让它的打包结果最优？

4. 可维护性：代码写完了，如何最小化它后续的变更成本？如何确保任何一个同事都能轻松接手？

以下三个方向都是时下比较流行的、普适性非常好的 CSS 工程化实践：

• 预处理器：Less、 Sass 等；

• 重要的工程化插件： PostCss；

• Webpack loader 等 。

基于这三个方向，可以衍生出一些具有典型意义的子问题，这里我们逐个来看：

（1）预处理器：为什么要用预处理器？它的出现是为了解决什么问题？

预处理器，其实就是 CSS 世界的“轮子”。预处理器支持我们写一种类似 CSS、但实际并不是 CSS 的语言，然后把它编译成 CSS 代码： 那为什么写 CSS 代码写得好好的，偏偏要转去写“类 CSS”呢？这就和本来用 JS 也可以实现所有功能，但最后却写 React 的 jsx 或者 Vue 的模板语法一样——为了爽！要想知道有了预处理器有多爽，首先要知道的是传统 CSS 有多不爽。随着前端业务复杂度的提高，前端工程中对 CSS 提出了以下的诉求：

1. 宏观设计上：我们希望能优化 CSS 文件的目录结构，对现有的 CSS 文件实现复用；

2. 编码优化上：我们希望能写出结构清晰、简明易懂的 CSS，需要它具有一目了然的嵌套层级关系，而不是无差别的一铺到底写法；我们希望它具有变量特征、计算能力、循环能力等等更强的可编程性，这样我们可以少写一些无用的代码；

3. 可维护性上：更强的可编程性意味着更优质的代码结构，实现复用意味着更简单的目录结构和更强的拓展能力，这两点如果能做到，自然会带来更强的可维护性。

这三点是传统 CSS 所做不到的，也正是预处理器所解决掉的问题。预处理器普遍会具备这样的特性：

• 嵌套代码的能力，通过嵌套来反映不同 css 属性之间的层级关系 ；

• 支持定义 css 变量；

• 提供计算函数；

• 允许对代码片段进行 extend 和 mixin；

• 支持循环语句的使用；

• 支持将 CSS 文件模块化，实现复用。

（2）PostCss：PostCss 是如何工作的？我们在什么场景下会使用 PostCss？

它和预处理器的不同就在于，预处理器处理的是 类 CSS，而 PostCss 处理的就是 CSS 本身。Babel 可以将高版本的 JS 代码转换为低版本的 JS 代码。PostCss 做的是类似的事情：它可以编译尚未被浏览器广泛支持的先进的 CSS 语法，还可以自动为一些需要额外兼容的语法增加前缀。更强的是，由于 PostCss 有着强大的插件机制，支持各种各样的扩展，极大地强化了 CSS 的能力。

PostCss 在业务中的使用场景非常多：

• 提高 CSS 代码的可读性：PostCss 其实可以做类似预处理器能做的工作；

• 当我们的 CSS 代码需要适配低版本浏览器时，PostCss 的 Autoprefixer 插件可以帮助我们自动增加浏览器前缀；

• 允许我们编写面向未来的 CSS：PostCss 能够帮助我们编译 CSS next 代码；

（3）Webpack 能处理 CSS 吗？如何实现？ Webpack 能处理 CSS 吗：

• Webpack 在裸奔的状态下，是不能处理 CSS 的，Webpack 本身是一个面向 JavaScript 且只能处理 JavaScript 代码的模块化打包工具；

• Webpack 在 loader 的辅助下，是可以处理 CSS 的。

如何用 Webpack 实现对 CSS 的处理：

• Webpack 中操作 CSS 需要使用的两个关键的 loader：css-loader 和 style-loader

• 注意，答出“用什么”有时候可能还不够，面试官会怀疑你是不是在背答案，所以你还需要了解每个 loader 都做了什么事情：

• css-loader：导入 CSS 模块，对 CSS 代码进行编译处理；

• style-loader：创建 style 标签，把 CSS 内容写入标签。

在实际使用中，css-loader 的执行顺序一定要安排在 style-loader 的前面。因为只有完成了编译过程，才可以对 css 代码进行插入；若提前插入了未编译的代码，那么 webpack 是无法理解这坨东西的，它会无情报错。

前端储存的⽅式有哪些？

• cookies： 在 HTML5 标准前本地储存的主要⽅式，优点是兼容性好，请求头⾃带 cookie⽅便，缺点是⼤⼩只有 4k，⾃动请求头加⼊cookie 浪费流量，每个 domain 限制 20 个 cookie，使⽤起来麻烦，需要⾃⾏封装；

• localStorage：HTML5 加⼊的以键值对(Key-Value)为标准的⽅式，优点是操作⽅便，永久性储存（除⾮⼿动删除），⼤⼩为 5M，兼容 IE8+ ；

• sessionStorage：与 localStorage 基本类似，区别是 sessionStorage 当⻚⾯关闭后会被清理，⽽且与 cookie、localStorage 不同，他不能在所有同源窗⼝中共享，是会话级别的储存⽅式；

• Web SQL：2010 年被 W3C 废弃的本地数据库数据存储⽅案，但是主流浏览器（⽕狐除外）都已经有了相关的实现，web sql 类似于 SQLite，是真正意义上的关系型数据库，⽤sql 进⾏操作，当我们⽤JavaScript 时要进⾏转换，较为繁琐；

• IndexedDB： 是被正式纳⼊HTML5 标准的数据库储存⽅案，它是 NoSQL 数据库，⽤键值对进⾏储存，可以进⾏快速读取操作，⾮常适合 web 场景，同时⽤JavaScript 进⾏操作会⾮常便。

display 的属性值及其作用

浏览器本地存储方式及使用场景

（1）Cookie

Cookie 是最早被提出来的本地存储方式，在此之前，服务端是无法判断网络中的两个请求是否是同一用户发起的，为解决这个问题，Cookie 就出现了。Cookie 的大小只有 4kb，它是一种纯文本文件，每次发起 HTTP 请求都会携带 Cookie。

Cookie 的特性：

• Cookie 一旦创建成功，名称就无法修改

• Cookie 是无法跨域名的，也就是说 a 域名和 b 域名下的 cookie 是无法共享的，这也是由 Cookie 的隐私安全性决定的，这样就能够阻止非法获取其他网站的 Cookie

• 每个域名下 Cookie 的数量不能超过 20 个，每个 Cookie 的大小不能超过 4kb

• 有安全问题，如果 Cookie 被拦截了，那就可获得 session 的所有信息，即使加密也于事无补，无需知道 cookie 的意义，只要转发 cookie 就能达到目的

• Cookie 在请求一个新的页面的时候都会被发送过去

如果需要域名之间跨域共享 Cookie，有两种方法：

1. 使用 Nginx 反向代理

2. 在一个站点登陆之后，往其他网站写 Cookie。服务端的 Session 存储到一个节点，Cookie 存储 sessionId

Cookie 的使用场景：

• 最常见的使用场景就是 Cookie 和 session 结合使用，我们将 sessionId 存储到 Cookie 中，每次发请求都会携带这个 sessionId，这样服务端就知道是谁发起的请求，从而响应相应的信息。

• 可以用来统计页面的点击次数

（2）LocalStorage

LocalStorage 是 HTML5 新引入的特性，由于有的时候我们存储的信息较大，Cookie 就不能满足我们的需求，这时候 LocalStorage 就派上用场了。

LocalStorage 的优点：

• 在大小方面，LocalStorage 的大小一般为 5MB，可以储存更多的信息

• LocalStorage 是持久储存，并不会随着页面的关闭而消失，除非主动清理，不然会永久存在

• 仅储存在本地，不像 Cookie 那样每次 HTTP 请求都会被携带

LocalStorage 的缺点：

• 存在浏览器兼容问题，IE8 以下版本的浏览器不支持

• 如果浏览器设置为隐私模式，那我们将无法读取到 LocalStorage

• LocalStorage 受到同源策略的限制，即端口、协议、主机地址有任何一个不相同，都不会访问

LocalStorage 的常用 API：

// 保存数据到 localStoragelocalStorage.setItem('key', 'value');
// 从 localStorage 获取数据let data = localStorage.getItem('key');
// 从 localStorage 删除保存的数据localStorage.removeItem('key');
// 从 localStorage 删除所有保存的数据localStorage.clear();
// 获取某个索引的KeylocalStorage.key(index)

LocalStorage 的使用场景：

• 有些网站有换肤的功能，这时候就可以将换肤的信息存储在本地的 LocalStorage 中，当需要换肤的时候，直接操作 LocalStorage 即可

• 在网站中的用户浏览信息也会存储在 LocalStorage 中，还有网站的一些不常变动的个人信息等也可以存储在本地的 LocalStorage 中

（3）SessionStorage

SessionStorage 和 LocalStorage 都是在 HTML5 才提出来的存储方案，SessionStorage 主要用于临时保存同一窗口(或标签页)的数据，刷新页面时不会删除，关闭窗口或标签页之后将会删除这些数据。

SessionStorage 与 LocalStorage 对比：

• SessionStorage 和 LocalStorage 都在本地进行数据存储；

• SessionStorage 也有同源策略的限制，但是 SessionStorage 有一条更加严格的限制，SessionStorage 只有在同一浏览器的同一窗口下才能够共享；

• LocalStorage 和 SessionStorage 都不能被爬虫爬取；

SessionStorage 的常用 API：

// 保存数据到 sessionStoragesessionStorage.setItem('key', 'value');
// 从 sessionStorage 获取数据let data = sessionStorage.getItem('key');
// 从 sessionStorage 删除保存的数据sessionStorage.removeItem('key');
// 从 sessionStorage 删除所有保存的数据sessionStorage.clear();
// 获取某个索引的KeysessionStorage.key(index)

SessionStorage 的使用场景

• 由于 SessionStorage 具有时效性，所以可以用来存储一些网站的游客登录的信息，还有临时的浏览记录的信息。当关闭网站之后，这些信息也就随之消除了。

什么是文档的预解析？

Webkit 和 Firefox 都做了这个优化，当执行 JavaScript 脚本时，另一个线程解析剩下的文档，并加载后面需要通过网络加载的资源。这种方式可以使资源并行加载从而使整体速度更快。需要注意的是，预解析并不改变 DOM 树，它将这个工作留给主解析过程，自己只解析外部资源的引用，比如外部脚本、样式表及图片。

如何判断元素是否到达可视区域

以图片显示为例：

• window.innerHeight 是浏览器可视区的高度；

• document.body.scrollTop || document.documentElement.scrollTop 是浏览器滚动的过的距离；

• imgs.offsetTop 是元素顶部距离文档顶部的高度（包括滚动条的距离）；

• 内容达到显示区域的：img.offsetTop < window.innerHeight + document.body.scrollTop;
  

进程与线程的概念

从本质上说，进程和线程都是 CPU 工作时间片的一个描述：

• 进程描述了 CPU 在运行指令及加载和保存上下文所需的时间，放在应用上来说就代表了一个程序。

• 线程是进程中的更小单位，描述了执行一段指令所需的时间。

进程是资源分配的最小单位，线程是 CPU 调度的最小单位。

一个进程就是一个程序的运行实例。详细解释就是，启动一个程序的时候，操作系统会为该程序创建一块内存，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的一个运行环境叫进程。进程是运行在虚拟内存上的，虚拟内存是用来解决用户对硬件资源的无限需求和有限的硬件资源之间的矛盾的。从操作系统角度来看，虚拟内存即交换文件；从处理器角度看，虚拟内存即虚拟地址空间。

如果程序很多时，内存可能会不够，操作系统为每个进程提供一套独立的虚拟地址空间，从而使得同一块物理内存在不同的进程中可以对应到不同或相同的虚拟地址，变相的增加了程序可以使用的内存。

进程和线程之间的关系有以下四个特点：

（1）进程中的任意一线程执行出错，都会导致整个进程的崩溃。

（2）线程之间共享进程中的数据。

（3）当一个进程关闭之后，操作系统会回收进程所占用的内存， 当一个进程退出时，操作系统会回收该进程所申请的所有资源；即使其中任意线程因为操作不当导致内存泄漏，当进程退出时，这些内存也会被正确回收。

（4）进程之间的内容相互隔离。 进程隔离就是为了使操作系统中的进程互不干扰，每一个进程只能访问自己占有的数据，也就避免出现进程 A 写入数据到进程 B 的情况。正是因为进程之间的数据是严格隔离的，所以一个进程如果崩溃了，或者挂起了，是不会影响到其他进程的。如果进程之间需要进行数据的通信，这时候，就需要使用用于进程间通信的机制了。

Chrome 浏览器的架构图： 从图中可以看出，最新的 Chrome 浏览器包括：

• 1 个浏览器主进程

• 1 个 GPU 进程

• 1 个网络进程

• 多个渲染进程

• 多个插件进程

这些进程的功能：

• 浏览器进程：主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。

• 渲染进程：核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。

• GPU 进程：其实， GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。

• 网络进程：主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。

• 插件进程：主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

所以，打开一个网页，最少需要四个进程：1 个网络进程、1 个浏览器进程、1 个 GPU 进程以及 1 个渲染进程。如果打开的页面有运行插件的话，还需要再加上 1 个插件进程。

虽然多进程模型提升了浏览器的稳定性、流畅性和安全性，但同样不可避免地带来了一些问题：

• 更高的资源占用：因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源。

• 更复杂的体系架构：浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了。

代码输出结果

Promise.resolve().then(() => {  console.log('promise1');  const timer2 = setTimeout(() => {    console.log('timer2')  }, 0)});const timer1 = setTimeout(() => {  console.log('timer1')  Promise.resolve().then(() => {    console.log('promise2')  })}, 0)console.log('start');

输出结果如下：

startpromise1timer1promise2timer2

代码执行过程如下：

1. 首先，Promise.resolve().then是一个微任务，加入微任务队列

2. 执行 timer1，它是一个宏任务，加入宏任务队列

3. 继续执行下面的同步代码，打印出start
   

4. 这样第一轮宏任务就执行完了，开始执行微任务Promise.resolve().then，打印出promise1
   

5. 遇到timer2，它是一个宏任务，将其加入宏任务队列，此时宏任务队列有两个任务，分别是timer1、timer2；

6. 这样第一轮微任务就执行完了，开始执行第二轮宏任务，首先执行定时器timer1，打印timer1；

7. 遇到Promise.resolve().then，它是一个微任务，加入微任务队列

8. 开始执行微任务队列中的任务，打印promise2；

9. 最后执行宏任务timer2定时器，打印出timer2；

Promise.resolve

Promise.resolve = function(value) {    // 1.如果 value 参数是一个 Promise 对象，则原封不动返回该对象    if(value instanceof Promise) return value;    // 2.如果 value 参数是一个具有 then 方法的对象，则将这个对象转为 Promise 对象，并立即执行它的then方法    if(typeof value === "object" && 'then' in value) {        return new Promise((resolve, reject) => {           value.then(resolve, reject);        });    }    // 3.否则返回一个新的 Promise 对象，状态为 fulfilled    return new Promise(resolve => resolve(value));}