关于javascript:前端经典面试题合集

默认代码从上到下执行，执行环境通过 script 来执行（宏工作）
在代码执行过程中，调用定时器 promise click事件 … 不会立刻执行，须要期待以后代码全副执行结束
给异步办法划分队列，别离寄存到微工作（立刻寄存）和宏工作（工夫到了或事件产生了才寄存）到队列中
script执行结束后，会清空所有的微工作
微工作执行结束后，会渲染页面（不是每次都调用）
再去宏工作队列中看有没有达到工夫的，拿进去其中一个执行
执行结束后，依照上述步骤不停的循环

例子

主动执行的状况会输入 listener1 listener2 task1 task2

如果手动点击 click 会一个宏工作取出来一个个执行，先执行 click 的宏工作，取出微工作去执行。会输入 listener1 task1 listener2 task2

console.log(1)

async function asyncFunc(){console.log(2)
  // await xx ==> promise.resolve(()=>{console.log(3)}).then()
  // console.log(3) 放到 promise.resolve 或立刻执行
  await console.log(3) 
  // 相当于把 console.log(4)放到了 then promise.resolve(()=>{console.log(3)}).then(()=>{//   console.log(4)
  // })
  // 微工作谁先注册谁先执行
  console.log(4)
}

setTimeout(()=>{console.log(5)})

const promise = new Promise((resolve,reject)=>{console.log(6)
  resolve(7)
})

promise.then(d=>{console.log(d)})

asyncFunc()

console.log(8)

// 输入 1 6 2 3 8 7 4 5

1. 浏览器事件循环

涉及面试题：异步代码执行程序？解释一下什么是 Event Loop？

JavaScript 的单线程，与它的用处无关。作为浏览器脚本语言，JavaScript 的主要用途是与用户互动，以及操作 DOM。这决定了它只能是单线程，否则会带来很简单的同步问题。比方，假设 JavaScript 同时有两个线程，一个线程在某个 DOM 节点上增加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？所以，为了防止复杂性，从一诞生，JavaScript 就是单线程，这曾经成了这门语言的外围特色，未来也不会扭转

js 代码执行过程中会有很多工作，这些工作总的分成两类：

同步工作
异步工作

当咱们关上网站时，网页的渲染过程就是一大堆同步工作，比方页面骨架和页面元素的渲染。而像加载图片音乐之类占用资源大耗时久的工作，就是异步工作。，咱们用导图来阐明：

咱们解释一下这张图：

同步和异步工作别离进入不同的执行 ” 场合 ”，同步的进入主线程，异步的进入 Event Table 并注册函数。
当指定的事件实现时，Event Table 会将这个函数移入 Event Queue。
主线程内的工作执行结束为空，会去 Event Queue 读取对应的函数，进入主线程执行。
上述过程会一直反复，也就是常说的 Event Loop(事件循环)。

那主线程执行栈何时为空呢？js 引擎存在 monitoring process 过程，会继续一直的查看主线程执行栈是否为空，一旦为空，就会去 Event Queue 那里查看是否有期待被调用的函数

以上就是 js 运行的整体流程

面试中该如何答复呢？上面是我集体举荐的答复：

首先 js 是单线程运行的，在代码执行的时候，通过将不同函数的执行上下文压入执行栈中来保障代码的有序执行
在执行同步代码的时候，如果遇到了异步事件，js 引擎并不会始终期待其返回后果，而是会将这个事件挂起，继续执行执行栈中的其余工作
当同步事件执行结束后，再将异步事件对应的回调退出到与以后执行栈中不同的另一个工作队列中期待执行
工作队列能够分为宏工作对列和微工作对列，当以后执行栈中的事件执行结束后，js 引擎首先会判断微工作对列中是否有工作能够执行，如果有就将微工作队首的事件压入栈中执行
当微工作对列中的工作都执行实现后再去判断宏工作对列中的工作。

setTimeout(function() {console.log(1)
}, 0);
new Promise(function(resolve, reject) {console.log(2);
  resolve()}).then(function() {console.log(3)
});
process.nextTick(function () {console.log(4)
})
console.log(5)

第一轮：主线程开始执行，遇到 setTimeout，将 setTimeout 的回调函数丢到宏工作队列中，在往下执行new Promise 立刻执行，输入 2，then 的回调函数丢到微工作队列中，再继续执行，遇到 process.nextTick，同样将回调函数扔到微工作队列，再继续执行，输入 5，当所有同步工作执行实现后看有没有能够执行的微工作，发现有 then 函数和nextTick 两个微工作，先执行哪个呢？process.nextTick指定的异步工作总是产生在所有异步工作之前，因而先执行 process.nextTick 输入 4 而后执行 then 函数输入 3，第一轮执行完结。
第二轮：从宏工作队列开始，发现 setTimeout 回调，输入 1 执行结束，因而后果是 25431

JS 在执行的过程中会产生执行环境，这些执行环境会被程序的退出到执行栈中。如果遇到异步的代码，会被挂起并退出到 Task（有多种 task）队列中。一旦执行栈为空，Event Loop 就会从 Task 队列中拿出须要执行的代码并放入执行栈中执行，所以实质上来说 JS 中的异步还是同步行为

console.log('script start');

setTimeout(function() {console.log('setTimeout');
}, 0);

console.log('script end');

不同的工作源会被调配到不同的 Task 队列中，工作源能够分为微工作（microtask）和宏工作（macrotask）。在 ES6 标准中，microtask 称为 jobs，macrotask 称为 task

console.log('script start');

setTimeout(function() {console.log('setTimeout');
}, 0);

new Promise((resolve) => {console.log('Promise')
    resolve()}).then(function() {console.log('promise1');
}).then(function() {console.log('promise2');
});

console.log('script end');
// script start => Promise => script end => promise1 => promise2 => setTimeout

以上代码尽管 setTimeout 写在 Promise 之前，然而因为 Promise 属于微工作而 setTimeout 属于宏工作

微工作

process.nextTick
promise
Object.observe
MutationObserver

宏工作

script
setTimeout
setInterval
setImmediate
I/O 网络申请实现、文件读写实现事件
UI rendering
用户交互事件（比方鼠标点击、滚动页面、放大放大等）

宏工作中包含了 script，浏览器会先执行一个宏工作，接下来有异步代码的话就先执行微工作

所以正确的一次 Event loop 程序是这样的

执行同步代码，这属于宏工作
执行栈为空，查问是否有微工作须要执行
执行所有微工作
必要的话渲染 UI
而后开始下一轮 Event loop，执行宏工作中的异步代码

通过上述的 Event loop 程序可知，如果宏工作中的异步代码有大量的计算并且须要操作 DOM 的话，为了更快的响应界面响应，咱们能够把操作 DOM 放入微工作中

JavaScript 引擎首先从宏工作队列（macrotask queue）中取出第一个工作
执行结束后，再将微工作（microtask queue）中的所有工作取出，依照程序别离全副执行（这里包含不仅指开始执行时队列里的微工作），如果在这一步过程中产生新的微工作，也须要执行；
而后再从宏工作队列中取下一个，执行结束后，再次将 microtask queue 中的全副取出，周而复始，直到两个 queue 中的工作都取完。

总结起来就是：一次 Eventloop 循环会解决一个宏工作和所有这次循环中产生的微工作。

2. Node 中的 Event loop

当 Node.js 开始启动时，会初始化一个 Eventloop，解决输出的代码脚本，这些脚本会进行 API 异步调用，process.nextTick() 办法会开始处理事件循环。上面就是 Node.js 官网提供的 Eventloop 事件循环参考流程

Node 中的 Event loop 和浏览器中的不雷同。
Node 的 Event loop 分为 6 个阶段，它们会依照程序重复运行

每次执行执行一个宏工作后会清空微工作（执行程序和浏览器统一，在 node11 版本以上）
process.nextTick node 中的微工作，以后执行栈的底部，优先级比 promise 要高

整个流程分为六个阶段，当这六个阶段执行完一次之后，才能够算得上执行了一次 Eventloop 的循环过程。咱们来别离看下这六个阶段都做了哪些事件。

Timers 阶段 ：这个阶段执行 setTimeout 和 setInterval 的回调函数，简略了解就是由这两个函数启动的回调函数。
I/O callbacks 阶段：这个阶段次要执行零碎级别的回调函数，比方 TCP 连贯失败的回调。
idle，prepare 阶段：仅零碎外部应用，你只须要晓得有这 2 个阶段就能够。
poll 阶段 ：poll 阶段是一个重要且简单的阶段，简直所有 I/O 相干的回调，都在这个阶段执行（除了setTimeout、setInterval、setImmediate 以及一些因为 exception 意外敞开产生的回调）。 检索新的 I/O 事件，执行与 I/O 相干的回调，其余状况 Node.js 将在适当的时候在此阻塞。这也是最简单的一个阶段，所有的事件循环以及回调解决都在这个阶段执行。这个阶段的次要流程如下图所示。

check 阶段：setImmediate() 回调函数在这里执行，setImmediate 并不是立马执行，而是当事件循环 poll 中没有新的事件处理时就执行该局部，如下代码所示。

const fs = require('fs');
setTimeout(() => { // 新的事件循环的终点
    console.log('1'); 
}, 0);
setImmediate(() => {console.log('setImmediate 1');
});
/// fs.readFile 将会在 poll 阶段执行
fs.readFile('./test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
    console.log('read file success');
});
/// 该局部将会在首次事件循环中执行
Promise.resolve().then(()=>{console.log('poll callback');
});
// 首次事件循环执行
console.log('2');

在这一代码中有一个十分奇异的中央，就是 setImmediate 会在 setTimeout 之后输入。有以下几点起因：

setTimeout 如果不设置工夫或者设置工夫为 0，则会默认为 1ms

主流程执行实现后，超过 1ms 时，会将 setTimeout 回调函数逻辑插入到待执行回调函数 poll 队列中；

因为以后 poll 队列中存在可执行回调函数，因而须要先执行完，待齐全执行实现后，才会执行check：setImmediate。

因而这也验证了这句话，先执行回调函数，再执行 setImmediate

close callbacks 阶段：执行一些敞开的回调函数，如 socket.on('close', ...)

除了把 Eventloop 的宏工作细分到不同阶段外。node 还引入了一个新的工作队列 Process.nextTick()

能够认为，Process.nextTick() 会在上述各个阶段完结时，在 进入下一个阶段之前立刻执行（优先级甚至超过 microtask 队列）

事件循环的次要蕴含微工作和宏工作。具体是怎么进行循环的呢

微工作 ：在 Node.js 中微工作蕴含 2 种——process.nextTick 和 Promise。 微工作在事件循环中优先级是最高的 ，因而在同一个事件循环中有其余工作存在时，优先执行微工作队列。并且process.nextTick 和 Promise 也存在优先级，process.nextTick 高于 Promise
宏工作：在 Node.js 中宏工作蕴含 4 种——setTimeout、setInterval、setImmediate 和 I/O。宏工作在微工作执行之后执行，因而在同一个事件循环周期内，如果既存在微工作队列又存在宏工作队列，那么优先将微工作队列清空，再执行宏工作队列

咱们能够看到有一个外围的主线程，它的执行阶段次要解决三个外围逻辑。

同步代码。
将异步工作插入到微工作队列或者宏工作队列中。
执行微工作或者宏工作的回调函数。在主线程解决回调函数的同时，也须要判断是否插入微工作和宏工作。依据优先级，先判断微工作队列是否存在工作，存在则先执行微工作，不存在则判断在宏工作队列是否有工作，有则执行。

const fs = require('fs');
// 首次事件循环执行
console.log('start');
/// 将会在新的事件循环中的阶段执行
fs.readFile('./test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
    console.log('read file success');
});
setTimeout(() => { // 新的事件循环的终点
    console.log('setTimeout'); 
}, 0);
/// 该局部将会在首次事件循环中执行
Promise.resolve().then(()=>{console.log('Promise callback');
});
/// 执行 process.nextTick
process.nextTick(() => {console.log('nextTick callback');
});
// 首次事件循环执行
console.log('end');

剖析下下面代码的执行过程

第一个事件循环主线程发动，因而先执行同步代码，所以先输入 start，而后输入 end
第一个事件循环主线程发动，因而先执行同步代码，所以先输入 start，而后输入 end；
再从上往下剖析，遇到微工作，插入微工作队列，遇到宏工作，插入宏工作队列，剖析实现后，微工作队列蕴含：Promise.resolve 和 process.nextTick，宏工作队列蕴含：fs.readFile 和 setTimeout；
先执行微工作队列，然而依据优先级，先执行 process.nextTick 再执行 Promise.resolve，所以先输入 nextTick callback 再输入 Promise callback；
再执行宏工作队列，依据 宏工作插入先后顺序执行 setTimeout 再执行 fs.readFile，这里须要留神，先执行 setTimeout 因为其回调工夫较短，因而回调也先执行，并非是 setTimeout 先执行所以才先执行回调函数，然而它执行须要工夫必定大于 1ms，所以尽管 fs.readFile 先于setTimeout 执行，然而 setTimeout 执行更快，所以先输入 setTimeout，最初输入 read file success。

// 输入后果
start
end
nextTick callback
Promise callback
setTimeout
read file success

当微工作和宏工作又产生新的微工作和宏工作时，又应该如何解决呢？如下代码所示：

const fs = require('fs');
setTimeout(() => { // 新的事件循环的终点
    console.log('1'); 
    fs.readFile('./config/test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
        console.log('read file sync success');
    });
}, 0);
/// 回调将会在新的事件循环之前
fs.readFile('./config/test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
    console.log('read file success');
});
/// 该局部将会在首次事件循环中执行
Promise.resolve().then(()=>{console.log('poll callback');
});
// 首次事件循环执行
console.log('2');

在下面代码中，有 2 个宏工作和 1 个微工作，宏工作是 setTimeout 和 fs.readFile，微工作是 Promise.resolve。

整个过程优先执行主线程的第一个事件循环过程，所以先执行同步逻辑，先输入 2。
接下来执行微工作，输入 poll callback。
再执行宏工作中的 fs.readFile 和 setTimeout，因为 fs.readFile 优先级高，先执行 fs.readFile。然而解决工夫长于 1ms，因而会先执行 setTimeout 的回调函数，输入 1。这个阶段在执行过程中又会产生新的宏工作 fs.readFile，因而又将该 fs.readFile 插入宏工作队列
最初因为只剩下宏工作了 fs.readFile，因而执行该宏工作，并期待解决实现后的回调，输入 read file sync success。

// 后果
2
poll callback
1
read file success
read file sync success

Process.nextick() 和 Vue 的 nextick

Node.js 和浏览器端宏工作队列的另一个很重要的不同点是，浏览器端工作队列每轮事件循环仅出队一个回调函数接着去执行微工作队列；而 Node.js 端只有轮到执行某个宏工作队列，则会执行完队列中所有的当前任务，然而以后轮次新增加到队尾的工作则会等到下一轮次才会执行。

setTimeout(() => {console.log('setTimeout');
}, 0);
setImmediate(() => {console.log('setImmediate');
})
// 这里可能会输入 setTimeout，setImmediate
// 可能也会相同的输入，这取决于性能
// 因为可能进入 event loop 用了不到 1 毫秒，这时候会执行 setImmediate
// 否则会执行 setTimeout

下面介绍的都是 macrotask 的执行状况，microtask 会在以上每个阶段实现后立刻执行

setTimeout(()=>{console.log('timer1')

    Promise.resolve().then(function() {console.log('promise1')
    })
}, 0)

setTimeout(()=>{console.log('timer2')

    Promise.resolve().then(function() {console.log('promise2')
    })
}, 0)

// 以上代码在浏览器和 node 中打印状况是不同的
// 浏览器中肯定打印 timer1, promise1, timer2, promise2
// node 中可能打印 timer1, timer2, promise1, promise2
// 也可能打印 timer1, promise1, timer2, promise2

Node 中的 process.nextTick 会先于其余 microtask 执行

setTimeout(() => {console.log("timer1");

 Promise.resolve().then(function() {console.log("promise1");
 });
}, 0);

// poll 阶段执行
fs.readFile('./test',()=>{
  // 在 poll 阶段外面 如果有 setImmediate 优先执行，setTimeout 处于事件循环顶端 poll 上面就是 setImmediate
  setTimeout(()=>console.log('setTimeout'),0)
  setImmediate(()=>console.log('setImmediate'),0)
})

process.nextTick(() => {console.log("nextTick");
});
// nextTick, timer1, promise1,setImmediate,setTimeout

对于 microtask 来说，它会在以上每个阶段实现前清空 microtask 队列，下图中的 Tick 就代表了 microtask

谁来启动这个循环过程，循环条件是什么？

当 Node.js 启动后，会初始化事件循环，解决已提供的输出脚本，它可能会先调用一些异步的 API、调度定时器，或者 process.nextTick()，而后再开始处理事件循环。因而能够这样了解，Node.js 过程启动后，就发动了一个新的事件循环，也就是事件循环的终点。

总结来说，Node.js 事件循环的发动点有 4 个：

Node.js 启动后；
setTimeout 回调函数；
setInterval 回调函数；
也可能是一次 I/O 后的回调函数。

有限循环有没有起点

当所有的微工作和宏工作都清空的时候，尽管以后没有工作可执行了，然而也并不能代表循环完结了。因为可能存在以后还未回调的异步 I/O，所以这个循环是没有起点的，只有过程在，并且有新的工作存在，就会去执行

Node.js 是单线程的还是多线程的？

主线程是单线程执行的 ，然而 Node.js 存在多线程执行 ，多线程包含 setTimeout 和异步 I/O 事件。其实 Node.js 还存在其余的线程，包含 垃圾回收、内存优化 等

EventLoop 对渲染的影响

想必你之前在业务开发中也遇到过 requestIdlecallback 和 requestAnimationFrame，这两个函数在咱们之前的内容中没有讲过，然而当你开始思考它们在 Eventloop 的生命周期的哪一步触发，或者这两个办法的回调会在微工作队列还是宏工作队列执行的时候，才发现如同没有设想中那么简略。这两个办法其实也并不属于 JS 的原生办法，而是浏览器宿主环境提供的办法，因为它们牵扯到另一个问题：渲染。
咱们晓得浏览器作为一个简单的利用是多线程工作的，除了运行 JS 的线程外，还有渲染线程、定时器触发线程、HTTP 申请线程，等等。JS 线程能够读取并且批改 DOM，而渲染线程也须要读取 DOM，这是一个典型的多线程竞争临界资源的问题。所以浏览器就把这两个线程设计成互斥的，即同时只能有一个线程在执行
渲染本来就不应该呈现在 Eventloop 相干的常识体系里，然而因为 Eventloop 显然是在探讨 JS 如何运行的问题，而渲染则是浏览器另外一个线程的工作。然而 requestAnimationFrame的呈现却把这两件事件给关联起来
通过调用 requestAnimationFrame 咱们能够在下次渲染之前执行回调函数。那下次渲染具体是哪个工夫点呢？渲染和 Eventloop 有什么关系呢？
- 简略来说，就是在每一次 Eventloop 的开端，判断以后页面是否处于渲染机会，就是从新渲染
有屏幕的硬件限度，比方 60Hz 刷新率，简而言之就是 1 秒刷新了 60 次，16.6ms 刷新一次。这个时候浏览器的渲染间隔时间就没必要小于 16.6ms，因为就算渲染了屏幕上也看不到。当然浏览器也不能保障肯定会每 16.6ms 会渲染一次，因为还会受到处理器的性能、JavaScript 执行效率等其余因素影响。
回到 requestAnimationFrame，这个 API 保障在下次浏览器渲染之前肯定会被调用，实际上咱们齐全能够把它看成是一个高级版的 setInterval。它们都是在一段时间后执行回调，然而前者的间隔时间是由浏览器本人一直调整的，而后者只能由用户指定。这样的个性也决定了 requestAnimationFrame 更适宜用来做针对每一帧来批改的动画成果
当然 requestAnimationFrame 不是 Eventloop 里的宏工作，或者说它并不在 Eventloop 的生命周期里，只是浏览器又凋谢的一个在渲染之前产生的新的 hook。另外须要留神的是微工作的认知概念也须要更新，在执行 animation callback 时也有可能产生微工作（比方 promise 的 callback），会放到 animation queue 解决完后再执行。所以微工作并不是像之前说的那样在每一轮 Eventloop 后处理，而是在 JS 的函数调用栈清空后处理

然而 requestIdlecallback 却是一个更好了解的概念。当宏工作队列中没有工作能够解决时，浏览器可能存在“闲暇状态”。这段闲暇工夫能够被 requestIdlecallback 利用起来执行一些优先级不高、不用立刻执行的工作，如下图所示：

当执行 JS 代码时，会产生三种执行上下文

全局执行上下文
函数执行上下文
eval 执行上下文

每个执行上下文中都有三个重要的属性

变量对象（VO），蕴含变量、函数申明和函数的形参，该属性只能在全局上下文中拜访
作用域链（JS 采纳词法作用域，也就是说变量的作用域是在定义时就决定了）
this

var a = 10
function foo(i) {var b = 20}
foo()

对于上述代码，执行栈中有两个上下文：全局上下文和函数 foo 上下文。

stack = [
    globalContext,
    fooContext
]

对于全局上下文来说，VO大略是这样的

globalContext.VO === globe
globalContext.VO = {
    a: undefined,
    foo: <Function>,
}

对于函数 foo 来说，VO 不能拜访，只能拜访到流动对象（AO）

fooContext.VO === foo.AO
fooContext.AO {
    i: undefined,
    b: undefined,
    arguments: <>
}
// arguments 是函数独有的对象(箭头函数没有)
// 该对象是一个伪数组，有 `length` 属性且能够通过下标拜访元素
// 该对象中的 `callee` 属性代表函数自身
// `caller` 属性代表函数的调用者

对于作用域链，能够把它了解成蕴含本身变量对象和下级变量对象的列表，通过 [[Scope]]属性查找下级变量

fooContext.[[Scope]] = [globalContext.VO]
fooContext.Scope = fooContext.[[Scope]] + fooContext.VO
fooContext.Scope = [
    fooContext.VO,
    globalContext.VO
]

接下来让咱们看一个陈词滥调的例子，var

b() // call b
console.log(a) // undefined

var a = 'Hello world'

function b() {console.log('call b')
}

想必以上的输入大家必定都曾经明确了，这是因为函数和变量晋升的起因。通常晋升的解释是说将申明的代码移动到了顶部，这其实没有什么谬误，便于大家了解。然而更精确的解释应该是：在生成执行上下文时，会有两个阶段。第一个阶段是创立的阶段（具体步骤是创立 VO），JS 解释器会找出须要晋升的变量和函数，并且给他们提前在内存中开拓好空间，函数的话会将整个函数存入内存中，变量只申明并且赋值为 undefined，所以在第二个阶段，也就是代码执行阶段，咱们能够间接提前应用。

在晋升的过程中，雷同的函数会笼罩上一个函数，并且函数优先于变量晋升

b() // call b second

function b() {console.log('call b fist')
}
function b() {console.log('call b second')
}
var b = 'Hello world'

var会产生很多谬误，所以在 ES6中引入了 let。let不能在申明前应用，然而这并不是常说的 let 不会晋升，let 晋升了申明但没有赋值，因为长期死区导致了并不能在申明前应用。

对于非匿名的立刻执行函数须要留神以下一点

var foo = 1
(function foo() {
    foo = 10
    console.log(foo)
}()) // -> ƒ foo() { foo = 10 ; console.log(foo) }

因为当 JS 解释器在遇到非匿名的立刻执行函数时，会创立一个辅助的特定对象，而后将函数名称作为这个对象的属性，因而函数外部才能够拜访到 foo，然而这个值又是只读的，所以对它的赋值并不失效，所以打印的后果还是这个函数，并且内部的值也没有产生更改。

specialObject = {};

Scope = specialObject + Scope;

foo = new FunctionExpression;
foo.[[Scope]] = Scope;
specialObject.foo = foo; // {DontDelete}, {ReadOnly}

delete Scope[0]; // remove specialObject from the front of scope chain

总结

执行上下文能够简略了解为一个对象:

它蕴含三个局部:

变量对象(VO)
作用域链(词法作用域)
this指向

它的类型:

全局执行上下文
函数执行上下文
eval执行上下文

代码执行过程:

创立全局上下文 (global EC)
全局执行上下文 (caller) 逐行自上而下执行。遇到函数时，函数执行上下文 (callee) 被 push 到执行栈顶层
函数执行上下文被激活，成为 active EC, 开始执行函数中的代码，caller 被挂起
函数执行完后，callee 被 pop 移除出执行栈，控制权交还全局上下文 (caller)，继续执行

同步指的是当一个过程在执行某个申请时，如果这个申请须要期待一段时间能力返回，那么这个过程会始终期待上来，直到音讯返回为止再持续向下执行。
异步指的是当一个过程在执行某个申请时，如果这个申请须要期待一段时间能力返回，这个时候过程会持续往下执行，不会阻塞期待音讯的返回，当音讯返回时零碎再告诉过程进行解决。

作用域：作用域是定义变量的区域，它有一套拜访变量的规定，这套规定来治理浏览器引擎如何在以后作用域以及嵌套的作用域中依据变量（标识符）进行变量查找
作用域链：作用域链的作用是保障对执行环境有权拜访的所有变量和函数的有序拜访，通过作用域链，咱们能够拜访到外层环境的变量和函数。

作用域链的实质上是一个指向变量对象的指针列表。变量对象是一个蕴含了执行环境中所有变量和函数的对象。作用域链的前端始终都是以后执行上下文的变量对象。全局执行上下文的变量对象（也就是全局对象）始终是作用域链的最初一个对象。

当咱们查找一个变量时，如果以后执行环境中没有找到，咱们能够沿着作用域链向后查找
作用域链的创立过程跟执行上下文的建设无关 ….

作用域能够了解为变量的可拜访性，总共分为三种类型，别离为：

全局作用域
函数作用域
块级作用域，ES6 中的 let、const 就能够产生该作用域

其实看完后面的闭包、this 这部分外部的话，应该根本能理解作用域的一些利用。

一旦咱们将这些作用域嵌套起来，就变成了另外一个重要的知识点「作用域链」，也就是 JS 到底是如何拜访须要的变量或者函数的。

首先作用域链是在定义时就被确定下来的，和箭头函数里的 this 一样，后续不会扭转，JS 会一层层往上寻找须要的内容。
其实作用域链这个货色咱们在闭包小结中曾经看到过它的实体了：[[Scopes]]

图中的 [[Scopes]] 是个数组，作用域的一层层往上寻找就等同于遍历 [[Scopes]]。

1. 全局作用域

全局变量是挂载在 window 对象下的变量，所以在网页中的任何地位你都能够应用并且拜访到这个全局变量

var globalName = 'global';
function getName() {console.log(globalName) // global
  var name = 'inner'
  console.log(name) // inner
} 
getName();
console.log(name); // 
console.log(globalName); //global
function setName(){vName = 'setName';}
setName();
console.log(vName); // setName

从这段代码中咱们能够看到，globalName 这个变量无论在什么中央都是能够被拜访到的，所以它就是全局变量。而在 getName 函数中作为局部变量的 name 变量是不具备这种能力的
当然全局作用域有相应的毛病，咱们定义很多全局变量的时候，会容易引起变量命名的抵触，所以在定义变量的时候应该留神作用域的问题。

2. 函数作用域

函数中定义的变量叫作函数变量，这个时候只能在函数外部能力拜访到它，所以它的作用域也就是函数的外部，称为函数作用域

function getName () {
  var name = 'inner';
  console.log(name); //inner
}
getName();
console.log(name);

除了这个函数外部，其余中央都是不能拜访到它的。同时，当这个函数被执行完之后，这个局部变量也相应会被销毁。所以你会看到在 getName 函数里面的 name 是拜访不到的

3. 块级作用域

ES6 中新增了块级作用域，最间接的体现就是新增的 let 关键词，应用 let 关键词定义的变量只能在块级作用域中被拜访，有“暂时性死区”的特点，也就是说这个变量在定义之前是不能被应用的。

在 JS 编码过程中 if 语句 及 for 语句前面 {...} 这外面所包含的，就是 块级作用域

console.log(a) //a is not defined
if(true){
  let a = '123'；console.log(a)；// 123
}
console.log(a) //a is not defined

从这段代码能够看出，变量 a 是在 if 语句 {...} 中由 let 关键词 进行定义的变量，所以它的作用域是 if 语句括号中的那局部，而在里面进行拜访 a 变量是会报错的，因为这里不是它的作用域。所以在 if 代码块的前后输入 a 这个变量的后果，控制台会显示 a 并没有定义

实际上，DNS 解析是一个蕴含迭代查问和递归查问的过程。

递归查问 指的是查问申请收回后，域名服务器代为向下一级域名服务器发出请求，最初向用户返回查问的最终后果。应用递归查问，用户只须要收回一次查问申请。
迭代查问 指的是查问申请后，域名服务器返回单次查问的后果。下一级的查问由用户本人申请。应用迭代查问，用户须要收回屡次的查问申请。

个别咱们向本地 DNS 服务器发送申请的形式就是递归查问，因为咱们只须要收回一次申请，而后本地 DNS 服务器返回给我们最终的申请后果。而本地 DNS 服务器向其余域名服务器申请的过程是迭代查问的过程，因为每一次域名服务器只返回单次查问的后果，下一级的查问由本地 DNS 服务器本人进行。

function parseParam(url) {const paramsStr = /.+\?(.+)$/.exec(url)[1]; // 将 ? 前面的字符串取出来
    const paramsArr = paramsStr.split('&'); // 将字符串以 & 宰割后存到数组中
    let paramsObj = {};
    // 将 params 存到对象中
    paramsArr.forEach(param => {if (/=/.test(param)) { // 解决有 value 的参数
            let [key, val] = param.split('='); // 宰割 key 和 value
            val = decodeURIComponent(val); // 解码
            val = /^\d+$/.test(val) ? parseFloat(val) : val; // 判断是否转为数字

            if (paramsObj.hasOwnProperty(key)) { // 如果对象有 key，则增加一个值
                paramsObj[key] = [].concat(paramsObj[key], val);
            } else { // 如果对象没有这个 key，创立 key 并设置值
                paramsObj[key] = val;
            }
        } else { // 解决没有 value 的参数
            paramsObj[param] = true;
        }
    })

    return paramsObj;
}

当初的办法也不肯定是平安的，因为没有方法确定失去的公钥就肯定是平安的公钥。可能存在一个中间人，截取了对方发给咱们的公钥，而后将他本人的公钥发送给咱们，当咱们应用他的公钥加密后发送的信息，就能够被他用本人的私钥解密。而后他伪装成咱们以同样的办法向对方发送信息，这样咱们的信息就被窃取了，然而本人还不晓得。为了解决这样的问题，能够应用数字证书。

首先应用一种 Hash 算法来对公钥和其余信息进行加密，生成一个信息摘要，而后让有公信力的认证核心（简称 CA）用它的私钥对音讯摘要加密，造成签名。最初将原始的信息和签名合在一起，称为数字证书。当接管方收到数字证书的时候，先依据原始信息应用同样的 Hash 算法生成一个摘要，而后应用公证处的公钥来对数字证书中的摘要进行解密，最初将解密的摘要和生成的摘要进行比照，就能发现失去的信息是否被更改了。

这个办法最要的是认证核心的可靠性，个别浏览器里会内置一些顶层的认证核心的证书，相当于咱们主动信赖了他们，只有这样能力保证数据的平安。

作用域晋升，将扩散的模块划分到同一个作用域中，防止了代码的反复引入，无效缩小打包后的代码体积和运行时的内存损耗；

长处：1. 体验好，不刷新，缩小 申请  数据 ajax 异步获取 页面流程；2. 前后端拆散

3. 加重服务端压力

4. 共用一套后端程序代码，适配多端

毛病：1. 首屏加载过慢；2.SEO 不利于搜索引擎抓取

参考：前端进阶面试题具体解答

题目形容: 实现一个你认为不错的 js 继承形式

实现代码如下:

function Parent(name) {
  this.name = name;
  this.say = () => {console.log(111);
  };
}
Parent.prototype.play = () => {console.log(222);
};
function Children(name) {Parent.call(this);
  this.name = name;
}
Children.prototype = Object.create(Parent.prototype);
Children.prototype.constructor = Children;
// let child = new Children("111");
// // console.log(child.name);
// // child.say();
// // child.play();

class EventEmitter {constructor() {this.cache = {}
    }
    on(name, fn) {if (this.cache[name]) {this.cache[name].push(fn)
        } else {this.cache[name] = [fn]
        }
    }
    off(name, fn) {let tasks = this.cache[name]
        if (tasks) {const index = tasks.findIndex(f => f === fn || f.callback === fn)
            if (index >= 0) {tasks.splice(index, 1)
            }
        }
    }
    emit(name, once = false, ...args) {if (this.cache[name]) {
            // 创立正本，如果回调函数内持续注册雷同事件，会造成死循环
            let tasks = this.cache[name].slice()
            for (let fn of tasks) {fn(...args)
            }
            if (once) {delete this.cache[name]
            }
        }
    }
}

// 测试
let eventBus = new EventEmitter()
let fn1 = function(name, age) {console.log(`${name} ${age}`)
}
let fn2 = function(name, age) {console.log(`hello, ${name} ${age}`)
}
eventBus.on('aaa', fn1)
eventBus.on('aaa', fn2)
eventBus.emit('aaa', false, '布兰', 12)
// '布兰 12'
// 'hello, 布兰 12'

为了解决跨浏览器兼容性问题，React 会将浏览器原生事件（Browser Native Event）封装为合成事件（SyntheticEvent）传入设置的事件处理器中。这里的合成事件提供了与原生事件雷同的接口，不过它们屏蔽了底层浏览器的细节差别，保障了行为的一致性。另外有意思的是，React 并没有间接将事件附着到子元素上，而是以繁多事件监听器的形式将所有的事件发送到顶层进行解决。这样 React 在更新 DOM 的时候就不须要思考如何去解决附着在 DOM 上的事件监听器，最终达到优化性能的目标

所有的事件挂在 document 上，DOM 事件触发后冒泡到 document；React 找到对应的组件，造出一个合成事件进去；并按组件树模仿一遍事件冒泡。
event 不是原生的，是 SyntheticEvent 合成事件对象
和 Vue 事件不同, 和 DOM 事件也不同

React 17 之前的事件冒泡流程图

所以这就造成了，在一个页面中，只能有一个版本的 React。如果有多个版本，事件就乱套了。值得一提的是，这个问题在 React 17 中失去了解决，事件委托不再挂在 document 上，而是挂在 DOM 容器上，也就是 ReactDom.Render 所调用的节点上。

React 17 后的事件冒泡流程图

那到底哪些事件会被捕捉生成合成事件呢？能够从 React 的源码测试文件中一探到底。上面的测试快照中列举了大量的事件名，也只有在这份快照中的事件，才会被捕捉生成合成事件。

// react/packages/react-dom/src/__tests__/__snapshots__/ReactTestUtils-test.js.snap
Array [
      "abort",
      "animationEnd",
      "animationIteration",
      "animationStart",
      "auxClick",
      "beforeInput",
      "blur",
      "canPlay",
      "canPlayThrough",
      "cancel",
      "change",
      "click",
      "close",
      "compositionEnd",
      "compositionStart",
      "compositionUpdate",
      "contextMenu",
      "copy",
      "cut",
      "doubleClick",
      "drag",
      "dragEnd",
      "dragEnter",
      "dragExit",
      "dragLeave",
      "dragOver",
      "dragStart",
      "drop",
      "durationChange",
      "emptied",
      "encrypted",
      "ended",
      "error",
      "focus",
      "gotPointerCapture",
      "input",
      "invalid",
      "keyDown",
      "keyPress",
      "keyUp",
      "load",
      "loadStart",
      "loadedData",
      "loadedMetadata",
      "lostPointerCapture",
      "mouseDown",
      "mouseEnter",
      "mouseLeave",
      "mouseMove",
      "mouseOut",
      "mouseOver",
      "mouseUp",
      "paste",
      "pause",
      "play",
      "playing",
      "pointerCancel",
      "pointerDown",
      "pointerEnter",
      "pointerLeave",
      "pointerMove",
      "pointerOut",
      "pointerOver",
      "pointerUp",
      "progress",
      "rateChange",
      "reset",
      "scroll",
      "seeked",
      "seeking",
      "select",
      "stalled",
      "submit",
      "suspend",
      "timeUpdate",
      "toggle",
      "touchCancel",
      "touchEnd",
      "touchMove",
      "touchStart",
      "transitionEnd",
      "volumeChange",
      "waiting",
      "wheel",
    ]

如果 DOM 上绑定了过多的事件处理函数, 整个页面响应以及内存占用可能都会受到影响。React 为了防止这类 DOM 事件滥用, 同时屏蔽底层不同浏览器之间的事件零碎的差别, 实现了一个中间层 – SyntheticEvent

当用户在为 onClick 增加函数时,React 并没有将 Click 绑定到 DOM 下面
而是在 document 处监听所有反对的事件, 当事件产生并冒泡至 document 处时,React 将事件内容封装交给中间层 SyntheticEvent (负责所有事件合成)
所以当事件触发的时候, 对应用对立的散发函数 dispatchEvent 将指定函数执行

为何要合成事件

兼容性和跨平台
挂在对立的 document 上，缩小内存耗费，防止频繁解绑
不便事件的对立治理（事务机制）
dispatchEvent 事件机制

DNS 占用 53 号端口，同时应用 TCP 和 UDP 协定。（1）在区域传输的时候应用 TCP 协定

辅域名服务器会定时（个别 3 小时）向主域名服务器进行查问以便理解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送应用 TCP 而不是 UDP，因为数据同步传送的数据量比一个申请应答的数据量要多得多。
TCP 是一种牢靠连贯，保障了数据的准确性。

（2）在域名解析的时候应用 UDP 协定

客户端向 DNS 服务器查问域名，个别返回的内容都不超过 512 字节，用 UDP 传输即可。不必通过三次握手，这样 DNS 服务器负载更低，响应更快。实践上说，客户端也能够指定向 DNS 服务器查问时用 TCP，但事实上，很多 DNS 服务器进行配置的时候，仅反对 UDP 查问包。

这里你谈 promise的时候，除了将他解决的痛点以及罕用的 API 之外，最好进行拓展把 eventloop 带进来好好讲一下，microtask(微工作)、macrotask(工作) 的执行程序，如果看过 promise 源码，最好能够谈一谈原生 Promise 是如何实现的。Promise 的关键点在于callback 的两个参数，一个是 resovle，一个是 reject。还有就是 Promise 的链式调用（Promise.then()，每一个 then 都是一个责任人）

Promise 是 ES6 新增的语法，解决了回调天堂的问题。
能够把 Promise看成一个状态机。初始是 pending 状态，能够通过函数 resolve 和 reject，将状态转变为 resolved 或者 rejected 状态，状态一旦扭转就不能再次变动。
then 函数会返回一个 Promise 实例，并且该返回值是一个新的实例而不是之前的实例。因为 Promise 标准规定除了 pending 状态，其余状态是不能够扭转的，如果返回的是一个雷同实例的话，多个 then 调用就失去意义了。对于 then 来说，实质上能够把它看成是 flatMap

1. Promise 的根本状况

简略来说它就是一个容器，外面保留着某个将来才会完结的事件（通常是异步操作）的后果。从语法上说，Promise 是一个对象，从它能够获取异步操作的音讯

个别 Promise 在执行过程中，必然会处于以下几种状态之一。

待定（pending）：初始状态，既没有被实现，也没有被回绝。
已实现（fulfilled）：操作胜利实现。
已回绝（rejected）：操作失败。

待定状态的 Promise 对象执行的话，最初要么会通过一个值实现，要么会通过一个起因被回绝。当其中一种状况产生时，咱们用 Promise 的 then 办法排列起来的相干处理程序就会被调用。因为最初 Promise.prototype.then 和 Promise.prototype.catch 办法返回的是一个 Promise，所以它们能够持续被链式调用

对于 Promise 的状态流转状况，有一点值得注意的是，外部状态扭转之后不可逆，你须要在编程过程中加以留神。文字描述比拟艰涩，咱们间接通过一张图就能很清晰地看出 Promise 外部状态流转的状况

从上图能够看出，咱们最开始创立一个新的 Promise 返回给 p1，而后开始执行，状态是 pending，当执行 resolve之后状态就切换为 fulfilled，执行 reject 之后就变为 rejected 的状态

2. Promise 的静态方法

all 办法
- 语法：Promise.all（iterable）
- 参数：一个可迭代对象，如 Array。
- 形容：此办法对于汇总多个 promise 的后果很有用，在 ES6 中能够将多个 Promise.all 异步申请并行操作，返回后果个别有上面两种状况。
  - 当所有后果胜利返回时依照申请程序返回胜利后果。
  - 当其中有一个失败办法时，则进入失败办法
咱们来看下业务的场景，对于上面这个业务场景页面的加载，将多个申请合并到一起，用 all 来实现可能成果会更好，请看代码片段

// 在一个页面中须要加载获取轮播列表、获取店铺列表、获取分类列表这三个操作，页面须要同时发出请求进行页面渲染，这样用 `Promise.all` 来实现，看起来更清晰、高深莫测。//1. 获取轮播数据列表
function getBannerList(){return new Promise((resolve,reject)=>{setTimeout(function(){resolve('轮播数据')
      },300) 
  })
}
//2. 获取店铺列表
function getStoreList(){return new Promise((resolve,reject)=>{setTimeout(function(){resolve('店铺数据')
    },500)
  })
}
//3. 获取分类列表
function getCategoryList(){return new Promise((resolve,reject)=>{setTimeout(function(){resolve('分类数据')
    },700)
  })
}
function initLoad(){Promise.all([getBannerList(),getStoreList(),getCategoryList()])
  .then(res=>{console.log(res) 
  }).catch(err=>{console.log(err)
  })
} 
initLoad()

allSettled 办法
- Promise.allSettled 的语法及参数跟 Promise.all 相似，其参数承受一个 Promise 的数组，返回一个新的 Promise。惟一的不同在于，执行完之后不会失败，也就是说当 Promise.allSettled 全副解决实现后，咱们能够拿到每个 Promise 的状态，而不论其是否解决胜利
咱们来看一下用 allSettled 实现的一段代码

const resolved = Promise.resolve(2);
const rejected = Promise.reject(-1);
const allSettledPromise = Promise.allSettled([resolved, rejected]);
allSettledPromise.then(function (results) {console.log(results);
});
// 返回后果：// [//    { status: 'fulfilled', value: 2},
//    {status: 'rejected', reason: -1}
// ]

从下面代码中能够看到，Promise.allSettled 最初返回的是一个数组，记录传进来的参数中每个 Promise 的返回值，这就是和 all 办法不太一样的中央。

any 办法
- 语法：Promise.any（iterable）
- 参数：iterable 可迭代的对象，例如 Array。
- 形容：any 办法返回一个 Promise，只有参数 Promise 实例有一个变成 fulfilled状态，最初 any返回的实例就会变成 fulfilled 状态；如果所有参数 Promise 实例都变成 rejected 状态，包装实例就会变成 rejected 状态。

const resolved = Promise.resolve(2);
const rejected = Promise.reject(-1);
const anyPromise = Promise.any([resolved, rejected]);
anyPromise.then(function (results) {console.log(results);
});
// 返回后果：// 2

从革新后的代码中能够看出，只有其中一个 Promise 变成 fulfilled状态，那么 any 最初就返回这个p romise。因为下面 resolved 这个 Promise 曾经是 resolve 的了，故最初返回后果为 2

race 办法
- 语法：Promise.race（iterable）
- 参数：iterable 可迭代的对象，例如 Array。
- 形容：race办法返回一个 Promise，只有参数的 Promise 之中有一个实例率先扭转状态，则 race 办法的返回状态就跟着扭转。那个率先扭转的 Promise 实例的返回值，就传递给 race 办法的回调函数
咱们来看一下这个业务场景，对于图片的加载，特地适宜用 race 办法来解决，将图片申请和超时判断放到一起，用 race 来实现图片的超时判断。请看代码片段。

// 申请某个图片资源
function requestImg(){var p = new Promise(function(resolve, reject){var img = new Image();
    img.onload = function(){ resolve(img); }
    img.src = 'http://www.baidu.com/img/flexible/logo/pc/result.png';
  });
  return p;
}
// 延时函数，用于给申请计时
function timeout(){var p = new Promise(function(resolve, reject){setTimeout(function(){reject('图片申请超时'); }, 5000);
  });
  return p;
}
Promise.race([requestImg(), timeout()])
.then(function(results){console.log(results);
})
.catch(function(reason){console.log(reason);
});


// 从下面的代码中能够看出，采纳 Promise 的形式来判断图片是否加载胜利，也是针对 Promise.race 办法的一个比拟好的业务场景

promise 手写实现，面试够用版：

function myPromise(constructor){
    let self=this;
    self.status="pending" // 定义状态扭转前的初始状态
    self.value=undefined;// 定义状态为 resolved 的时候的状态
    self.reason=undefined;// 定义状态为 rejected 的时候的状态
    function resolve(value){
        // 两个 ==="pending"，保障了状态的扭转是不可逆的
       if(self.status==="pending"){
          self.value=value;
          self.status="resolved";
       }
    }
    function reject(reason){
        // 两个 ==="pending"，保障了状态的扭转是不可逆的
       if(self.status==="pending"){
          self.reason=reason;
          self.status="rejected";
       }
    }
    // 捕捉结构异样
    try{constructor(resolve,reject);
    }catch(e){reject(e);
    }
}
// 定义链式调用的 then 办法
myPromise.prototype.then=function(onFullfilled,onRejected){
   let self=this;
   switch(self.status){
      case "resolved":
        onFullfilled(self.value);
        break;
      case "rejected":
        onRejected(self.reason);
        break;
      default:       
   }
}

浅拷贝：只思考对象类型。

function shallowCopy(obj) {if (typeof obj !== 'object') return

    let newObj = obj instanceof Array ? [] : {}
    for (let key in obj) {if (obj.hasOwnProperty(key)) {newObj[key] = obj[key]
        }
    }
    return newObj
}

简略版深拷贝：只思考一般对象属性，不思考内置对象和函数。

function deepClone(obj) {if (typeof obj !== 'object') return;
    var newObj = obj instanceof Array ? [] : {};
    for (var key in obj) {if (obj.hasOwnProperty(key)) {newObj[key] = typeof obj[key] === 'object' ? deepClone(obj[key]) : obj[key];
        }
    }
    return newObj;
}

简单版深克隆：基于简略版的根底上，还思考了内置对象比方 Date、RegExp 等对象和函数以及解决了循环援用的问题。

const isObject = (target) => (typeof target === "object" || typeof target === "function") && target !== null;

function deepClone(target, map = new WeakMap()) {if (map.get(target)) {return target;}
    // 获取以后值的构造函数：获取它的类型
    let constructor = target.constructor;
    // 检测以后对象 target 是否与正则、日期格局对象匹配
    if (/^(RegExp|Date)$/i.test(constructor.name)) {// 创立一个新的非凡对象 (正则类 / 日期类) 的实例
        return new constructor(target);  
    }
    if (isObject(target)) {map.set(target, true);  // 为循环援用的对象做标记
        const cloneTarget = Array.isArray(target) ? [] : {};
        for (let prop in target) {if (target.hasOwnProperty(prop)) {cloneTarget[prop] = deepClone(target[prop], map);
            }
        }
        return cloneTarget;
    } else {return target;}
}

1. 公布 / 订阅模式

公布 / 订阅模式
- 订阅者
- 发布者
- 信号核心

咱们假设，存在一个 ” 信号核心 ”，某个工作执行实现，就向信号核心 ” 公布 ”(publish)一个信号，其余工作能够向信号核心 ” 订阅 ”(subscribe)这个信号，从而晓得什么时候本人能够开始执行。这就叫做 ” 公布 / 订阅模式 ”(publish-subscribe pattern)

Vue 的自定义事件

let vm = new Vue()
vm.$on('dataChange', () => {console.log('dataChange')})
vm.$on('dataChange', () => {console.log('dataChange1')
}) 
vm.$emit('dataChange')

兄弟组件通信过程

// eventBus.js
// 事件核心
let eventHub = new Vue()

// ComponentA.vue
// 发布者
addTodo: function () {// 公布音讯(事件)
  eventHub.$emit('add-todo', { text: this.newTodoText}) 
  this.newTodoText = ''
}
// ComponentB.vue
// 订阅者
created: function () {// 订阅音讯(事件)
  eventHub.$on('add-todo', this.addTodo)
}

模仿 Vue 自定义事件的实现

class EventEmitter {constructor(){// { eventType: [ handler1, handler2] }
    this.subs = {}}
  // 订阅告诉
  $on(eventType, fn) {this.subs[eventType] = this.subs[eventType] || []
    this.subs[eventType].push(fn)
  }
  // 公布告诉
  $emit(eventType) {if(this.subs[eventType]) {this.subs[eventType].forEach(v=>v())
    }
  }
}

// 测试
var bus = new EventEmitter()

// 注册事件
bus.$on('click', function () {console.log('click')
})

bus.$on('click', function () {console.log('click1')
})

// 触发事件 
bus.$emit('click')

2. 观察者模式

观察者(订阅者) — Watcher
- update(): 当事件产生时，具体要做的事件
指标(发布者) — Dep
- subs 数组: 存储所有的观察者
- addSub(): 增加观察者
- notify(): 当事件产生，调用所有观察者的 update() 办法
没有事件核心

// 指标(发布者) 
// Dependency
class Dep {constructor () {
    // 存储所有的观察者
    this.subs = []}
  // 增加观察者
  addSub (sub) {if (sub && sub.update) {this.subs.push(sub)
    }
  }
  // 告诉所有观察者
  notify () {this.subs.forEach(sub => sub.update())
  }
}

// 观察者(订阅者)
class Watcher {update () {console.log('update')
  }
}

// 测试
let dep = new Dep()
let watcher = new Watcher()
dep.addSub(watcher) 
dep.notify()

3. 总结

观察者模式 是由具体指标调度，比方当事件触发，Dep 就会去调用观察者的办法，所以观察者模式的订阅者与发布者之间是存在依赖的
公布 / 订阅模式 由对立调度核心调用，因而发布者和订阅者不须要晓得对方的存在

事后设置一些参数

柯里化是什么：是指这样一个函数，它接管函数 A，并且能返回一个新的函数，这个新的函数可能处理函数 A 的残余参数

function createCurry(func, args) {
  var argity = func.length;
  var args = args || [];

  return function () {var _args = [].slice.apply(arguments);
    args.push(..._args);

    if (args.length < argity) {return createCurry.call(this, func, args);
    }

    return func.apply(this, args);
  }
}

1、首先创立了一个新对象
2、设置原型，将对象的原型设置为函数的 prototype 对象
3、让函数的 this 指向这个对象，执行构造函数的代码（为这个新对象增加属性）4、判断函数的返回值类型，如果是值类型，返回创立的对象。如果是援用类型，就返回这个援用类型的对象

父子组件通信
自定义事件
redux 和 context

context 如何使用

父组件向其下所有子孙组件传递信息
如一些简略的信息：主题、语言
简单的公共信息用 redux

在跨层级通信中，次要分为一层或多层的状况

如果只有一层，那么依照 React 的树形构造进行分类的话，次要有以下三种状况：父组件向子组件通信 ， 子组件向父组件通信 以及 平级的兄弟组件间相互通信。
在父与子的状况下，因为 React 的设计实际上就是传递 Props 即可。那么场景体现在容器组件与展现组件之间，通过 Props 传递 state，让展现组件受控。
在子与父的状况下 ，有两种形式，别离是回调函数与实例函数。回调函数，比方输入框向父级组件返回输出内容，按钮向父级组件传递点击事件等。实例函数的状况有些特地，次要是在父组件中 通过 React 的 ref API 获取子组件的实例 ，而后是 通过实例调用子组件的实例函数。这种形式在过来常见于 Modal 框的显示与暗藏
多层级间的数据通信，有两种状况。第一种是一个容器中蕴含了多层子组件，须要最底部的子组件与顶部组件进行通信。在这种状况下，如果一直透传 Props 或回调函数，不仅代码层级太深，后续也很不好保护。第二种是两个组件不相干，在整个 React 的组件树的两侧，齐全不相交。那么基于多层级间的通信个别有三个计划。
- 第一个是应用 React 的 Context API，最常见的用处是做语言包国际化
- 第二个是应用全局变量与事件。
- 第三个是应用状态治理框架，比方 Flux、Redux 及 Mobx。长处是因为引入了状态治理，使得我的项目的开发模式与代码构造得以束缚，毛病是学习老本绝对较高

React 组件应从 设计与工程实际 两个方向进行探讨

从设计上而言，社区支流分类的计划是展现组件与乖巧组件

展现组件外部没有状态治理，仅仅用于最简略的展现表白。展现组件中最根底的一类组件称作代理组件。代理组件罕用于封装罕用属性、缩小反复代码。很经典的场景就是引入 Antd 的 Button 时，你再本人封一层。如果将来须要替换掉 Antd 或者须要在所有的 Button 上增加一个属性，都会十分不便。基于代理组件的思维还能够持续分类，分为款式组件与布局组件两种，别离是将款式与布局内聚在本人组件外部。
从工程实际而言，通过文件夹划分的形式切分代码。我初步罕用的宰割形式是将页面独自建设一个目录，将复用性略高的 components 建设一个目录，在上面别离建设 basic、container 和 hoc 三类。这样能够保障无奈复用的业务逻辑代码尽量留在 Page 中，而能够形象复用的局部放入 components 中。其中 basic 文件夹放展现组件，因为展现组件自身与业务关联性较低，所以能够应用 Storybook 进行组件的开发治理，晋升我的项目的工程化治理能力

事件循环

执行上下文

同步和异步的区别

作用域

迭代查问与递归查问

解析 URL 参数为对象

数字证书是什么？

介绍一下 webpack scope hosting

说一下 SPA 单页面有什么优缺点？

寄生组合继承

事件总线（公布订阅模式）

合成事件原理

DNS 同时应用 TCP 和 UDP 协定？

Promise

深浅拷贝

公布订阅模式和观察者模式

手写题：实现柯里化

New 操作符做了什么事件?

组件之间通信

如何设计 React 组件

站内搜索