` 元素加一个特殊的 `is` attribute 来实现，也就是动态组件：
1000 |
1001 | ```markup
1002 |
1003 |
1004 | ```
1005 |
1006 | 在上述示例中，`currentTabComponent` 可以包括
1007 |
1008 | * 已注册组件的名字，或
1009 | * 一个组件的选项对象
1010 |
1011 | {% hint style="info" %}
1012 | 动态组件也可以使用 keep-alive 进行缓存
1013 | {% endhint %}
1014 |
1015 | ## 异步组件
1016 |
1017 | 在大型应用中，我们可能需要将应用分割成小一些的代码块，并且只在需要的时候才从服务器加载一个模块，这个就是异步组件加载。
1018 |
1019 | ### 异步组件的全局注册
1020 |
1021 | ```javascript
1022 |
1023 |
1024 |
1028 |
1029 |
1030 |
1031 |
1032 |
1033 |
1034 |
1035 |
1068 |
1070 | ```
1071 |
1072 | ### 异步组件的局部注册
1073 |
1074 | 异步组建的局部注册唯一的区别就是 `components` 的写法
1075 |
1076 | ```javascript
1077 | components: {
1078 | AddCustomerSchedule(resolve) {
1079 | require(["../components/AddCustomer"], resolve);
1080 | },
1081 | AddPeopleSchedule(resolve) {
1082 | require(["../components/AddPeople"], resolve);
1083 | },
1084 | CustomerInfoSchedule(resolve) {
1085 | require(["../components/CustomerInfo"], resolve);
1086 | },
1087 | VisitRecordSchedule(resolve) {
1088 | require(["../components/VisitRecord"], resolve);
1089 | },
1090 | },
1091 | ```
1092 |
1093 | ## 递归组件
1094 |
1095 | 有的时候，本来想秀下操作，然而由于 ~~水平菜鸡~~ 业务复杂，稍有不慎我们就很容易写出死循环的递归组件：
1096 |
1097 | ```javascript
1098 | name: 'stack-overflow',
1099 | template: '
'
1100 | ```
1101 |
1102 | 类似上述的组件将会导致“max stack size exceeded”错误，所以请确保递归调用是条件性的 \(例如使用一个最终会得到 `false` 的 `v-if`\)。
1103 |
1104 | ## 组件的循环引用
1105 |
1106 | 组件间的循环引入的场景之一就是—— **tree 组件**。导致死循环引用的原因，其实是因为两个 vue 文件中的循环 import，webpack 打包这种文件的时候，就会不知所措，于是只能给你抛出一个错误。所以这种场景往往出现在局部注册的组件下，而 `Vue.component()` 进行的全局组件注册由于不存在循环引用，所以没有这个问题。
1107 |
1108 | 对于这个问题的解决方案有两种：
1109 |
1110 | 1. 你可以在 beforeCreate 钩子函数里进行引入：
1111 |
1112 | ```javascript
1113 | beforeCreate: function () {
1114 | this.$options.components.TreeFolderContents = require('./tree-folder-contents.vue').default
1115 | }
1116 | ```
1117 |
1118 | 2. 你可以在注册局部组件的时候，使用动态组件的注册方式：
1119 |
1120 | ```javascript
1121 | components: {
1122 | TreeFolderContents: () => import('./tree-folder-contents.vue')
1123 | }
1124 | ```
1125 |
1126 | 两种解决问题的核心思想，都是延迟引入，从而规避掉 webpack 打包时可能出现的懵逼情况。
1127 |
1128 | ## keep-alive
1129 |
1130 | keep-alive 多出来两个钩子函数 `activated` 和 `deactivated` 。用 `keep-alive` 包裹的组件在切换时不会进行销毁，而是缓存到内存中并执行 `deactivated` 钩子函数，命中缓存渲染后会执行 `actived` 钩子函数。
1131 |
1132 | 对于这个知识点，一般也就问问它是做什么用的，也不太会问别的东西，毕竟没有什么值得深挖的。只要能答上来这个是做组件缓存的基本就没问题。想要详细了解的，这里给个传送门吧：[keep-alive](https://cn.vuejs.org/v2/api/#keep-alive)
1133 |
1134 | ## 分发插槽
1135 |
1136 | 当我们需要在自定义组件中再嵌套自定义组件，就会用到 **“分发插槽”** 的功能，这个就类似于 React 中的语法 `{...this.children}` ：
1137 |
1138 | ### 默认插槽
1139 |
1140 | Vue 组件支持一个默认默认插槽，默认插槽有得话只能有一个：
1141 |
1142 | ```markup
1143 |
1144 |
1145 | Hello world!
1146 |
1147 |
1148 |
1149 |
1150 |
1151 |
1152 |
1153 |
1154 |
1155 | Hello world!
1156 |
1157 | ```
1158 |
1159 | 你也可以为插槽提供一个后备用内容，当父组件没有任何东西插入的时候，后备内容就会默认显示，像这样：
1160 |
1161 | ```markup
1162 |
1163 |
1164 | Hi World!
1165 |
1166 | ```
1167 |
1168 | ### 具名插槽
1169 |
1170 | 具名插槽可以有很多，不过名称不能重复，具名插槽和默认插槽可以同时存在：
1171 |
1172 | ```markup
1173 |
1174 |
1175 | This is header
1176 | This is body
1177 | Hello World!
1178 |
1179 |
1180 |
1181 |
1182 |
1183 |
1184 |
1185 |
1186 |
1187 |
1188 |
1189 | This is header
1190 | This is body
1191 | Hello world!
1192 |
1193 | ```
1194 |
1195 | ### 作用域插槽
1196 |
1197 | 当使用插槽的时候，父级模板里的所有内容都是在父级作用域中编译的；子模板里的所有内容都是在子作用域中编译的。也就是说，子元素没有办法访问到父模板中的内容，那么这个时候可以使用作用域插槽来将父模板里的内容传入:
1198 |
1199 | ```markup
1200 |
1201 |
1202 |
1203 | {{ slotProps.user.firstName }}
1204 |
1205 |
1206 |
1207 |
1208 |
1209 |
1210 | {{ user.lastName }}
1211 |
1212 |
1213 | ```
1214 |
1215 | 如果是默认插槽的 `prop` 可以使用简写：
1216 |
1217 | ```markup
1218 |
1219 |
1220 |
1221 | {{ slotProps.user.firstName }}
1222 |
1223 |
1224 |
1225 |
1226 |
1227 |
1228 | {{ user.lastName }}
1229 |
1230 |
1231 | ```
1232 |
1233 | {% hint style="warning" %}
1234 | **注意** 默认插槽的缩写语法 **不能** 和具名插槽混用，因为它会导致作用域不明确
1235 | {% endhint %}
1236 |
1237 | ```markup
1238 |
1239 |
1240 |
1241 | {{ slotProps.user.firstName }}
1242 |
1243 | slotProps is NOT available here
1244 |
1245 |
1246 | ```
1247 |
1248 | {% hint style="warning" %}
1249 | 只要出现多个插槽，请始终为_所有的_插槽使用完整的基于 `` 的语法
1250 | {% endhint %}
1251 |
1252 | ```markup
1253 |
1254 |
1255 |
1256 | {{ slotProps.user.firstName }}
1257 |
1258 |
1259 |
1260 | ...
1261 |
1262 |
1263 | ```
1264 |
1265 | 可以以为结构的方式写插槽
1266 |
1267 | ```markup
1268 |
1269 |
1270 |
1271 | {{ .user.firstName }}
1272 |
1273 |
1274 | ```
1275 |
1276 | ### 动态插槽
1277 |
1278 | 动态指令参数也可以用在 `v-slot` 上，来定义动态的插槽名
1279 |
1280 | ```markup
1281 |
1282 |
1283 | ...
1284 |
1285 |
1286 | ```
1287 |
1288 | ### 具名插槽缩写
1289 |
1290 | ```markup
1291 |
1292 |
1293 | Here might be a page title
1294 |
1295 |
1296 | A paragraph for the main content.
1297 | And another one.
1298 |
1299 |
1300 | Here's some contact info
1301 |
1302 |
1303 | ```
1304 |
1305 | 加入作用域插槽
1306 |
1307 | ```markup
1308 |
1309 | {{ slotProps.user.firstName }}
1310 |
1311 | ```
1312 |
1313 | ## 混入
1314 |
1315 | 我们写一些相似度很高的组件时，经常会发现很多能够提取出来公共使用的东西部分，Vue 对于这部分内容，提供了一个混入的工具：**mixin。**`mixin` 对象，其实也就是普通的 `vue` 对象而已。
1316 |
1317 | ### 全局混入 Mixin
1318 |
1319 | ```javascript
1320 | Vue.mixin({
1321 | beforeCreate() {
1322 | // ...逻辑
1323 | // 这种方式会影响到每个组件的 beforeCreate 钩子函数
1324 | }
1325 | })
1326 | ```
1327 |
1328 | ### 局部混入 Mixins
1329 |
1330 | ```javascript
1331 | const mixinObj = {
1332 | methods: {
1333 | mixinFunc() {}
1334 | }
1335 | }
1336 |
1337 | new Vue({
1338 | mixins: [mixinObj],
1339 | created() {
1340 | this.mixinFunc();
1341 | }
1342 | });
1343 | ```
1344 |
1345 | {% hint style="warning" %}
1346 | 使用 mixin 混入时：
1347 |
1348 | * mixin 的钩子函数会再自己组件的钩子函数之前触发
1349 | * 对于 methods、computed 这些配置项等，Vue 会进行合并
1350 | * 对于同名属性，Vue 会用组件里的来覆盖 mixin 的
1351 | {% endhint %}
1352 |
1353 | ### 自定义混入方式
1354 |
1355 | 这个我从来没有用过，也没有被问到过，感觉不重要也不常用，需要的话自取文档：[自定义选项合并策略](https://cn.vuejs.org/v2/guide/mixins.html#%E8%87%AA%E5%AE%9A%E4%B9%89%E9%80%89%E9%A1%B9%E5%90%88%E5%B9%B6%E7%AD%96%E7%95%A5)
1356 |
1357 | ### 混入和 extend
1358 |
1359 | Vue 里还有一个 `extend` 的 api，那么这个和 `mixin` 有什么区别呢？个人感觉这两个东西的目的都是一样的：**都是作为混入和扩展的一种方法**，只不过实现层面不同：`mixin` 是在组件层面混入，或者可以理解为对实例进行扩展；而 `extend` 是先扩展了构造函数也就是累类，然后根据这个扩展完成的类，在再进行实例化。看代码：
1360 |
1361 | ```javascript
1362 | // 创建组件构造器
1363 | let Component = Vue.extend({
1364 | template: 'test
'
1365 | })
1366 | // 挂载到 #app 上
1367 | new Component().$mount('#app')
1368 | // 除了上面的方式，还可以用来扩展已有的组件
1369 | let SuperComponent = Vue.extend(Component)
1370 | new SuperComponent({
1371 | created() {
1372 | console.log(1)
1373 | }
1374 | })
1375 | new SuperComponent().$mount('#app')
1376 | ```
1377 |
1378 | ## 自定义指令
1379 |
1380 | 这块内容不多，但是面试的时候可能会被提一句：**你有没有写过自定义指令？**所以我建议大家直接看官网：[自定义指令](https://cn.vuejs.org/v2/guide/custom-directive.html)，官网上介绍的很详细，关于自定义指令内容大部分是使用方式、传参细节等，没有太多的坑在里面。
1381 |
1382 | 这里提一下我认为有可能被深入问到的问题：
1383 |
1384 | {% hint style="info" %}
1385 | **你觉得指令和组件有什么区别？它们各自的应用场景是什么？**
1386 | {% endhint %}
1387 |
1388 | {% hint style="success" %}
1389 | 指令和组件主要的区别大概有两点：
1390 |
1391 | 1. **业务的复杂程度：**
1392 |
1393 | 复杂的业务不用说，肯定没法单纯用指令就能摆平，让开发者只用指令写一个弹出框出来，肯定也不现实。所以复杂的业务必须组件，可以用自定义指令来进行辅助。并且，从配置项上也能看出来，指令是包含在组件里面的。
1394 |
1395 | 2. **`DOM` 操作的频繁程度：**
1396 |
1397 | Vue 是数据驱动视图，本身是不提倡大量操作 DOM 的。然而实际开发场景中，我们有很多情况需要必须操作 DOM 。这个时候，就可以使用自定义指令来进行 DOM 操作，看上去也比在业务中直接用 jquery 获取来的优雅和语义化。常见的场景之一就是 affix 图钉——当用户界面滚动下来的时候，重要信息能有个吸顶的功能。
1398 | {% endhint %}
1399 |
1400 | ## 渲染函数和 JSX
1401 |
1402 | 从这块内容开始，说实话，Vue 的画风逐渐变态，已经开始在我这种白嫖党最不喜欢的 “底层” 、“原理” 这种关键词之间疯狂试谈。
1403 |
1404 | 里面的内容比较多，这里就不写了，我自觉不可能比官网写的好，大家还是把这块的官网内容看一下：[渲染函数 & JSX](https://cn.vuejs.org/v2/guide/render-function.html)。如果不太愿意看的朋友，就看我下面的总结大概：
1405 |
1406 | 1. 首先呢，我们现在开发 vue 的基本操作就是 **`.vue`** 文件了，我们在里面写的很爽，但是在最终 **Vue 的 compile** 编译阶段，会将我们的组件编译成如下的渲染函数的形式：
1407 |
1408 | ```markup
1409 |
1410 | 先写一些文字
1411 |
一则头条
1412 |
1413 |
1414 | ```
1415 |
1416 | 转换为：
1417 |
1418 | ```javascript
1419 |
1420 | new Vue({
1421 | render: function (createElement, context) {
1422 | return createElement(
1423 | 'div',
1424 | // 一个与模板中 attribute 对应的数据对象。可选。
1425 | {
1426 |
1427 | },
1428 | // 子元素
1429 | [
1430 | '先写一些文字',
1431 | createElement('h1', '一则头条'),
1432 | createElement(MyComponent, {
1433 | props: {
1434 | someProp: 'foobar'
1435 | }
1436 | })
1437 | ]);
1438 | }
1439 | });
1440 | ```
1441 |
1442 | 是不是看不懂？是不是看不懂？看不懂就对了，因为这个本来就不是给人看的，是编译成这种格式给机器运行的。
1443 |
1444 | 2. 拿到了编译完成的渲染函数并且执行后，vue 就能得到一个叫做 **`VNode`** 的 **虚拟 `DOM` 树**，这个**虚拟 `DOM` 树** 其实就是 **用普通 js 对象的格式，对于即将渲染成的 DOM 文档格式的一种抽象描述**。类似于下面这样：
1445 |
1446 | ```javascript
1447 | {
1448 | 'class': {
1449 | foo: true,
1450 | bar: false
1451 | },
1452 | style: {
1453 | color: 'red',
1454 | fontSize: '14px'
1455 | },
1456 | // 普通的 HTML attribute
1457 | attrs: {
1458 | id: 'foo'
1459 | },
1460 | // 组件 prop
1461 | props: {
1462 | myProp: 'bar'
1463 | },
1464 | // DOM property
1465 | domProps: {
1466 | innerHTML: 'baz'
1467 | },
1468 | on: {
1469 | click: this.clickHandler
1470 | },
1471 | nativeOn: {
1472 | click: this.nativeClickHandler
1473 | },
1474 | children: [...]
1475 | }
1476 | ```
1477 |
1478 | 3. 有了这个 **`VNode Tree`** 的虚拟文档描述，Vue 就可以 **将虚拟 DOM 渲染成真实的 DOM 节点**，然后一次插入。
1479 |
1480 | **至于为什么会有这个东西呢？**
1481 |
1482 | 1. 首先，我们写的很爽的 `template` 这种模板语言格式，浏览器是不认识的，更不会执行，这个只是一种对于开发者更友好的语法糖，将真正的底层全部封装，简化最大程度简化写法，让程序员聚焦业务。而 `render` 函数本质上是浏览器能够识别并执行的 `javascript` ，浏览器拿到就很开心。
1483 | 2. 写过 React 的朋友就知道，Vue 和 React 的差别之一，就是在于： **Vue 里面没办法大量地编写 javascript ，而 React 却可以**。Vue 的人性化语法极大地迎合了开发者，**但是这也造成了自由度没有 React 高**，毕竟 React 全部 js，就连 **`jsx`** 其实也是普通的 **`string`** 。那这种情况下，在某些 ~~SB需求~~ 更为复杂、需要高度自由的场景下，语法糖就不适用了，比如说 `table` 组件。那怎么兼得鱼和熊掌？vue 的 render 函数就提供了一个解决方案，可能看上去没有那么好看，也不好理解，但是它确实能解决你的需求。
1484 |
1485 | **至于最后的 JSX**
1486 |
1487 | 这也不是 Vue 官方推荐的东西，只不过考虑到这样的语法写起来确实难受，官方提供了一个可供选择的方案而已。
1488 |
1489 | ## 插件
1490 |
1491 | 内容不多，推荐看下官网：[插件](https://cn.vuejs.org/v2/guide/plugins.html)。
1492 |
1493 | 1. `Vue.use(plugin)` 注册插件
1494 | 2. 插件需要暴露一个 install 方法，接收 `Vue` 构造器和 `options` 选项作为参数：
1495 |
1496 | ```javascript
1497 | Plugin.install = function (Vue, options) {}
1498 | ```
1499 |
1500 | 3. 插件里面可以扩展 Vue 原型、扩展全局指令、扩展全局 mixin 等。
1501 |
1502 | ## 过滤器
1503 |
1504 | 内容不多，推荐看下官网：[过滤器](https://cn.vuejs.org/v2/guide/filters.html)。
1505 |
1506 | 1. 过滤器的挂载：
1507 |
1508 | ```javascript
1509 | new Vue({
1510 | filters: {
1511 | filter1 (value) {
1512 | return value + '';
1513 | }
1514 | }
1515 | });
1516 | ```
1517 |
1518 | 2. 过滤器的使用：
1519 |
1520 | ```markup
1521 | {{ message | filter1 }}
1522 |
1523 | {{ message | filter1(arg1, arg2) }}
1524 | ```
1525 |
1526 | ```javascript
1527 | new Vue({
1528 | filters: {
1529 | filter1 (value, arg1, arg2) {
1530 | return value;
1531 | }
1532 | }
1533 | });
1534 | ```
1535 |
1536 | 3. 过滤器的链式使用：
1537 |
1538 | ```markup
1539 |
1540 | {{ message | filter1 | filter2 }}
1541 | ```
1542 |
1543 | ## 参考文档
1544 |
1545 | * [Vue 官方文档](https://cn.vuejs.org/v2/guide/)
1546 | * [前端面试之道](https://juejin.cn/book/6844733763675488269/section/6844733763780345869)
1547 | * [Vue-- $attrs与$listeners的详解](https://www.jianshu.com/p/a388d38f8c69)
1548 | * [vue异步组件\(高级异步组件\)使用场景及实践](https://segmentfault.com/a/1190000012138052)
1549 | * [vue按需加载组件,异步组件](https://www.cnblogs.com/jun-qi/p/10931205.html)
1550 |
1551 |
--------------------------------------------------------------------------------
/frontend-frame/vue-frame.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Vue 框架的相关面试内容
3 | ---
4 |
5 | # Vue框架
6 |
7 | ## **生命周期**
8 |
9 | 1. 在 beforeCreate 钩子函数调用的时候，是获取不到 props 或者 data 中的数据的，因为这些数据的初始化都在 initState 中。
10 | 2. 然后会执行 created 钩子函数，在这一步的时候已经可以访问到之前不能访问到的数据，但是这时候组件还没被挂载，所以是看不到的。
11 | 3. 接下来会先执行 beforeMount 钩子函数，开始创建 VDOM，最后执行 mounted 钩子，并将 VDOM 渲染为真实 DOM 并且渲染数据。组件中如果有子组件的话，会递归挂载子组件，只有当所有子组件全部挂载完毕，才会执行根组件的挂载钩子。
12 | 4. 接下来是数据更新时会调用的钩子函数 beforeUpdate 和 updated，这两个钩子函数没什么好说的，就是分别在数据更新前和更新后会调用。
13 | 5. 另外还有 keep-alive 独有的生命周期，分别为 activated 和 deactivated 。用 keep-alive 包裹的组件在切换时不会进行销毁，而是缓存到内存中并执行 deactivated 钩子函数，命中缓存渲染后会执行 actived 钩子函数。
14 | 6. 最后就是销毁组件的钩子函数 beforeDestroy 和 destroyed。前者适合移除事件、定时器等等，否则可能会引起内存泄露的问题。然后进行一系列的销毁操作，如果有子组件的话，也会递归销毁子组件，所有子组件都销毁完毕后才会执行根组件的 destroyed 钩子函数。
15 |
16 | ## **组件通信**
17 |
18 | **父子通信：**
19 |
20 | 1. 子 $emit 父 / 父 props 子
21 | 2. v-model 语法糖，本质上是一个名为 value 的 Prop 传递到子组件，子组件发送 input 时间通知父组件
22 | 3. 可以通过 $parent / $children 来访问父 / 子组件中的数据和方法
23 | 4. $listeners 属性会将父组件中的 \(不含 .native 修饰器的\) v-on 事件监听器传递给子组件，子组件可以通过访问 $listeners 来自定义监听器。类似于 react 的子组件通知父组件的方式，父组件的回调作为 props 传入子组件
24 | 5. .sync 属性是个语法糖，可以实现简单的父子组件通信：
25 |
26 | ```text
27 |
28 |
29 |
30 |
31 |
32 |
35 | ```
36 |
37 | #### **兄弟组件通信**
38 |
39 | 对于这种情况可以通过查找父组件中的子组件实现，也就是 this.$parent.$children，在 $children 中可以通过组件 name 查询到需要的组件实例，然后进行通信。
40 |
41 | #### **跨层级组件通信**
42 |
43 | 使用 provide 和 inject （vue2.2+），这对选项需要一起使用，以允许一个祖先组件向其所有子孙后代注入一个依赖，不论组件层次有多深，并在起上下游关系成立的时间里始终生效。如果你熟悉 React，这与 React 的上下文特性很相似。
44 |
45 | **任意组件间的通信**
46 |
47 | 可以使用 Event bus 或者 vuex 通信，所谓 Event bus 就是再新床架一个空的 Vue 实例，然后通过这个实例的 $emit / $on 方法在任意出发送和接受事件并传递参数
48 |
49 | ## **extend 是用来做什么的**
50 |
51 | extend 通常用于挂载全局使用的组件而不需要在每一个需要用到的地方单独 import
52 |
53 | ```javascript
54 | // 创建组件构造器
55 | let Component = Vue.extend({
56 | template: 'test
'
57 | })
58 | // 挂载到 #app 上
59 | new Component().$mount('#app')
60 | // 除了上面的方式，还可以用来扩展已有的组件
61 | let SuperComponent = Vue.extend(Component)
62 | new SuperComponent({
63 | created() {
64 | console.log(1)
65 | }
66 | })
67 | new SuperComponent().$mount('#app')
68 | ```
69 |
70 | ## **mixin 和 mixins**
71 |
72 | 1. mixin 全局注入，mixins 局部注入
73 | 2. 另外需要注意的是 mixins 混入的钩子函数会先于组件内的钩子函数执行，并且在遇到同名选项的时候也会有选择性的进行合并，如果 mixins 和组件内属性同名，以组件内部为准
74 |
75 | ## **computed 和 watch**
76 |
77 | 1. computed 是计算属性，依赖其他属性计算值，并且 computed 的值有缓存，只有当计算值变化才会返回内容。擅长处理的场景：一个数据受多个数据影响
78 | 2. watch 监听到值的变化就会执行回调，在回调中可以进行一些逻辑操作。擅长处理的场景：一个数据印象多个数据
79 | 3. 所以一般来说需要依赖别的属性来动态获得值的时候可以使用 computed，对于监听到值的变化需要做一些复杂业务逻辑的情况可以使用 watch。
80 |
81 | ## **keep-alive 的作用**
82 |
83 | 1. 如果你需要在组件切换的时候，保存一些组件的状态防止多次渲染，就可以使用 keep-alive 组件包裹需要保存的组件。
84 | 2. 对于 keep-alive 组件来说，它拥有两个独有的生命周期钩子函数，分别为 activated 和 deactivated 。用 keep-alive 包裹的组件在切换时不会进行销毁，而是缓存到内存中并执行 deactivated 钩子函数，命中缓存渲染后会执行 actived 钩子函数。
85 |
86 | ## **v-show 与 v-if 区别**
87 |
88 | ## **组件中的 data 为什么不能使用对象**
89 |
90 | 使用对象的话，该组件的所有实例都会共享一个 data 了。
91 |
92 | ## **vue-element-admin 中权限控制**
93 |
94 | * `router` 中将路由分为了 `constantRoutes` （常量路由）和 `asyncRoutes` （动态路由）两个列表
95 | * `main.js` 中引入了路由守卫拦截文件 `permission.js`
96 | * 路由守卫中判断路由：
97 | * 如果 `store` 中有存储过的权限列表，放行
98 | * 否则去后端获取权限列表数据 `List`，获取到后根据后端的数据及 `asyncRoutes` 调用 `router.addRoute` 方法添加新的路由后，放行。这时，如果 `to.path` 在路由里，就跳转到对应页面，否则就跳转 404
99 | * 关键：根据后端数据使用 `router.addRoute` 动态生成 `vue` 路由
100 |
101 | ## 进阶
102 |
103 | Vue 深入原理可以查看[Vue.js 技术揭秘](https://ustbhuangyi.github.io/vue-analysis/)
104 |
105 |
--------------------------------------------------------------------------------
/frontend-frame/vue-ji-chu.md:
--------------------------------------------------------------------------------
1 | # Vue基础
2 |
3 | ### 数据与方法
4 |
5 | 当一个 Vue 实例被创建时，它将 `data` 对象中的所有的 property 加入到 Vue 的**响应式系统**中。当这些 property 的值发生改变时，视图将会产生“响应”，即匹配更新为新的值。当这些数据改变时，视图会进行重渲染。
6 |
7 | {% hint style="warning" %}
8 | **需要注意：**只有当实例被创建时就已经存在于 `data` 中的 property 才是**响应式**的。
9 | {% endhint %}
10 |
11 | 也就是说如果你添加一个新的 property，那么后续对于该 property 所作的改动将不会触发任何视图的更新。如果你知道你会在晚些时候需要一个 property，但是一开始它为空或不存在，那么你仅需要设置一些初始值。
12 |
13 | {% hint style="warning" %}
14 | 当使用 Object.freeze\(\) 对属性进行冻结时，Vue 系统将不再追踪 property 的变化
15 | {% endhint %}
16 |
17 | ### 生命周期
18 |
19 | {% hint style="info" %}
20 | 每个 Vue 实例在被创建时都要经过一系列的初始化过程——例如，需要设置数据监听、编译模板、将实例挂载到 DOM 并在数据变化时更新 DOM 等。同时在这个过程中也会运行一些叫做**生命周期钩子**的函数，这给了用户在不同阶段添加自己的代码的机会。
21 | {% endhint %}
22 |
23 | **Vue 的全部生命周期钩子（非 SSR）：**
24 |
25 | * **beforeCreate**
26 |
27 | 在实例初始化之后，数据观测 \(data observer\) 和 event/watcher 事件配置之前被调用。
28 |
29 | * **created**
30 |
31 | 在实例创建完成后被立即调用。在这一步，实例已完成以下的配置：数据观测 \(data observer\)，property 和方法的运算，watch/event 事件回调。然而，挂载阶段还没开始，`$el` property 目前尚不可用。
32 |
33 | * **beforeMount**
34 |
35 | 在挂载开始之前被调用：相关的 `render` 函数首次被调用。
36 |
37 | * **mounted**
38 |
39 | 实例被挂载后调用，这时 `el` 被新创建的 `vm.$el` 替换了。如果根实例挂载到了一个文档内的元素上，当 `mounted` 被调用时 `vm.$el` 也在文档内。
40 |
41 | **注意：** `mounted` **不会**保证所有的子组件也都一起被挂载。如果你希望等到整个视图都渲染完毕，可以在 `mounted` 内部使用 [vm.$nextTick](https://cn.vuejs.org/v2/api/#vm-nextTick)。
42 |
43 | * **beforeUpdate**
44 |
45 | 数据更新时调用，发生在虚拟 DOM 打补丁之前。这里适合在更新之前访问现有的 DOM，比如手动移除已添加的事件监听器。
46 |
47 | * **updated**
48 |
49 | 由于数据更改导致的虚拟 DOM 重新渲染和打补丁，在这之后会调用该钩子。
50 |
51 | 当这个钩子被调用时，组件 DOM 已经更新，所以你现在可以执行依赖于 DOM 的操作。**然而在大多数情况下，你应该避免在此期间更改状态**。如果要相应状态改变，通常最好使用[计算属性](https://cn.vuejs.org/v2/api/#computed)或 [watcher](https://cn.vuejs.org/v2/api/#watch) 取而代之。
52 |
53 | **注意：** `updated` **不会**保证所有的子组件也都一起被重绘。如果你希望等到整个视图都重绘完毕，可以在 `updated` 里使用 [vm.$nextTick](https://cn.vuejs.org/v2/api/#vm-nextTick)。
54 |
55 | * **activated**
56 |
57 | 被 keep-alive 缓存的组件激活时调用。
58 |
59 | * **deactivated**
60 |
61 | 被 keep-alive 缓存的组件停用时调用。
62 |
63 | * **beforeDestroy**
64 |
65 | 实例销毁之前调用。在这一步，实例仍然完全可用。
66 |
67 | * **destroyed**
68 |
69 | 实例销毁后调用。该钩子被调用后，对应 Vue 实例的所有指令都被解绑，所有的事件监听器被移除，所有的子实例也都被销毁。
70 |
71 | * **errorCaptured**
72 |
73 | 当捕获一个来自子孙组件的错误时被调用。此钩子会收到三个参数：错误对象、发生错误的组件实例以及一个包含错误来源信息的字符串。此钩子可以返回 `false` 以阻止该错误继续向上传播。
74 |
75 | {% hint style="info" %}
76 | **需要注意：**如果使用 Vue 的服务端渲染框架比如：Nestjs，那么生命周期中只有：**beforeCreate、created 和 errorCaptured** 有效。因为服务端渲染只负责第一屏，渲染完成后，后续的 DOM 挂载、数据变更、销毁等，均由浏览器接管。
77 | {% endhint %}
78 |
79 | {% hint style="warning" %}
80 | **需要注意：**所有的生命周期钩子自动绑定 `this` 上下文到实例中，因此你可以访问数据，对 property 和方法进行运算。这意味着**你不能使用箭头函数来定义一个生命周期方法** \(例如 `created: () => this.fetchTodos()`\)。这是因为箭头函数绑定了父上下文，因此 `this` 与你期待的 Vue 实例不同，`this.fetchTodos` 的行为未定义。
81 | {% endhint %}
82 |
83 | 下图是一个 Vue 实例的生命周期图谱：
84 |
85 | 
86 |
87 | #### 关于Vue生命周期的总结：
88 |
89 | 在 `beforeCreate` 钩子函数调用的时候，是获取不到 `props` 或者 `data` 中的数据的，因为这些数据的初始化都在 `initState` 中。
90 |
91 | 然后会执行 `created` 钩子函数，在这一步的时候已经可以访问到之前不能访问到的数据，但是这时候组件还没被挂载，所以是看不到的。
92 |
93 | 接下来会先执行 `beforeMount` 钩子函数，开始创建 VDOM，最后执行 `mounted` 钩子，并将 VDOM 渲染为真实 DOM 并且渲染数据。`mounted` **不会**保证所有的子组件也都一起被挂载。
94 |
95 | 接下来是数据更新时会调用的钩子函数 `beforeUpdate` 和 `updated`，这两个钩子函数分别在数据更新前和更新后会调用。
96 |
97 | 另外还有 `keep-alive` 独有的生命周期，分别为 `activated` 和 `deactivated` 。用 `keep-alive` 包裹的组件在切换时不会进行销毁，而是缓存到内存中并执行 `deactivated` 钩子函数，命中缓存渲染后会执行 `actived` 钩子函数。
98 |
99 | 最后就是销毁组件的钩子函数 `beforeDestroy` 和 `destroyed`。前者适合移除事件、定时器等等，否则可能会引起内存泄露的问题。然后进行一系列的销毁操作。
100 |
101 | ### 计算属性和侦听器
102 |
103 | #### 计算属性的使用场景：
104 |
105 | {% hint style="info" %}
106 | 当绑定在模板中的数据需要**依赖其他属性值进行计算，或者需要经过一些复杂计算、特殊处理才能渲染到页面上的时候**，我们可以使用计算属性：**computed**
107 | {% endhint %}
108 |
109 | #### **计算属性的特性：**
110 |
111 | {% hint style="info" %}
112 | 计算属性可以让你的绑定值依赖其他值的变化来进行动态计算，并且会根据依赖值进行缓存，只有当依赖值变化才会返回新的计算内容。
113 | {% endhint %}
114 |
115 | #### 计算属性和侦听器的区别：
116 |
117 | {% hint style="info" %}
118 | **computed** 是计算属性，依赖其他属性计算值，并且 **computed** 的值有缓存，只有当计算值变化才会返回内容。
119 |
120 | **watch** 监听到值的变化就会执行回调，在回调中可以进行一些逻辑操作。
121 |
122 | 所以一般来说需要依赖别的属性来动态获得值的时候可以使用 **computed**，对于监听到值的变化需要做一些复杂业务逻辑的情况可以使用 **watch**。
123 | {% endhint %}
124 |
125 | 计算属性和侦听器还支持对象形式的写法：
126 |
127 | ```javascript
128 | // watch
129 | vm.$watch('obj', {
130 | // 深度遍历
131 | deep: true,
132 | // 立即触发
133 | immediate: true,
134 | // 执行的函数
135 | handler: function(val, oldVal) {}
136 | })
137 |
138 | // computed
139 | var vm = new Vue({
140 | data: { a: 1 },
141 | computed: {
142 | aPlus: {
143 | // this.aPlus 时触发
144 | get: function () {
145 | return this.a + 1
146 | },
147 | // this.aPlus = 1 时触发
148 | set: function (v) {
149 | this.a = v - 1
150 | }
151 | }
152 | }
153 | });
154 | ```
155 |
156 | {% hint style="success" %}
157 | 设置侦听器 deep 为 true，则能开启对于对象属性的深度监听模式，也就是说，对象下的子属性发生变动，侦听器一样能够监测到变化并且触发。
158 | {% endhint %}
159 |
160 | #### 计算属性和方法的区别：
161 |
162 | 有的时候，计算属性和方法（methods）都可以达到相同的效果，那么它们之间的区别是什么呢？
163 |
164 | {% hint style="info" %}
165 | **计算属性是基于它们的响应式依赖进行缓存的**。只在相关响应式依赖发生改变时它们才会重新求值。这就意味着只要依赖值还没有发生改变，多次访问计算属性会立即返回之前的计算结果，而不必再次执行函数。
166 |
167 | 而 相比之下，每当触发重新渲染时，调用方法将**总会**再次执行函数，这是有性能损耗的。
168 | {% endhint %}
169 |
170 | ### Class 与 Style 绑定
171 |
172 | #### 自动添加前缀
173 |
174 | 当 `v-bind:style` 使用需要添加浏览器引擎前缀的 CSS property 时，如 `transform`，Vue.js 会自动侦测并添加相应的前缀。
175 |
176 | ### 条件渲染
177 |
178 | #### v-show 与 v-if 区别
179 |
180 | `v-show` 只是在 `display: none` 和 `display: block` 之间切换。无论初始条件是什么都会被渲染出来，后面只需要切换 CSS，DOM 还是一直保留着的。所以总的来说 `v-show` 在初始渲染时有更高的开销，但是切换开销很小，更适合于频繁切换的场景。
181 |
182 | `v-if` 的话就得说到 Vue 底层的编译了。当属性初始为 `false` 时，组件就不会被渲染，直到条件为 `true`，并且切换条件时会触发销毁/挂载组件，所以总的来说在切换时开销更高，更适合不经常切换的场景。
183 |
184 | 并且基于 `v-if` 的这种惰性渲染机制，可以在必要的时候才去渲染组件，减少整个页面的初始渲染开销。
185 |
186 | #### 用 `key` 管理可复用的元素
187 |
188 | `Vue` 的 `key` 这个东西官网上说的官方解释有些抽象，推荐大家看：[Vue2.0 v-for 中 :key 到底有什么用？](https://www.zhihu.com/question/61064119/answer/766607894)
189 |
190 | **简单来说：**
191 |
192 | * 如果这个元素没有加上 `key`，那么在 Vue 下一次更新视图的时候，它就会尽可能地将该元素进行复用，而不是重新创造一个新的元素将其替换。典型的场景是：表单登录，用户可以选择微信号或者手机号登录，当用户输入账号后忽然想切换登录方式，代码里虽然是使用的 v-if 进行了微信号和手机号两个 input 之间的切换，但是之前填写的登录账号信息依然会保留下来，这个就是 Vue 对 Input 标签进行了复用。
193 | * 如果这个元素上加了唯一的 `key` ，就等于说给这个元素及其子元素 / 子组件加上了一个唯一的 id 标识，那么 Vue 在下一次更新视图的时候，就能够识别出哪些元素是被修改了，哪些元素是被删除掉了，从而更有针对性地选择复用还是重建元素，而不是直接一股脑地能复用就复用。
194 |
195 | **官网解释：**
196 |
197 | `key` 的特殊 attribute 主要用在 Vue 的虚拟 DOM 算法，在新旧 nodes 对比时辨识 VNodes。如果不使用 key，Vue 会使用一种 **最大限度减少动态元素** 并且 **尽可能的尝试就地修改/复用相同类型元素** 的算法。而使用 key 时，**它会基于 key 的变化重新排列元素顺序，并且会移除 key 不存在的元素**。
198 |
199 | 有相同父元素的子元素必须有**独特的 key**。重复的 key 会造成渲染错误。
200 |
201 | 最常见的用例是结合 `v-for`：
202 |
203 | ```markup
204 |
207 | ```
208 |
209 | **它也可以用于强制替换元素/组件而不是重复使用它**。当你遇到如下场景时它可能会很有用：
210 |
211 | * **完整地触发组件的生命周期钩子**
212 | * **触发过渡**
213 |
214 | 例如：
215 |
216 | ```markup
217 |
218 | {{ text }}
219 |
220 | ```
221 |
222 | 当 `text` 发生改变时，`` 总是会被替换而不是被修改，因此会触发过渡。
223 |
224 | ### 列表渲染
225 |
226 | 这里的 `v-for` 指令就涉及到上面所说的 `key` 的问题。
227 |
228 | 假设有一个列表，列表有三个子组件，自组件没有加唯一 `key` 值，每个子组件里面有一个「有状态的」孙子组件。
229 |
230 | 
231 |
232 | 现在用户点击删除按钮，删除掉第二项，会出现以下结果：Vue 识别自组件 **2** 的名称被修改为 **3** 但是其他的东西都会进行复用，包括自组件，然后删除原来的 **3** 组件及其自组件。这就出现了问题。
233 |
234 | 
235 |
236 | {% hint style="warning" %}
237 | **不要使用 index 索引作为组件的 key！**因为，这样的话，当你删除了一项比如第二项，那么第三项组件的 key 就变成了 2 ，Vue 在进行 VNodes 比对的时候，还会认为是你只是将组件 2 的名称修改成了组件 3，然后还是会复用，于是还是会出现上面的问题。
238 | {% endhint %}
239 |
240 |
--------------------------------------------------------------------------------
/javascript-basics/execution-context.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | 当 JS
4 | 引擎处理一段脚本内容的时候，它是以怎样的顺序解析和执行的？脚本中的那些变量是何时被定义的？它们之间错综复杂的访问关系又是怎样创建和链接的？要解释这些问题，就必须了解
5 | JS 执行上下文的概念。
6 | ---
7 |
8 | # 执行上下文
9 |
10 | ### 什么是执行上下文
11 |
12 | 当 `JS` 引擎解析到可执行代码片段（通常是函数调用阶段）的时候，就会先做一些执行前的准备工作，这个 **“准备工作”**，就叫做 **"执行上下文\(execution context 简称 `EC`\)"** 或者也可以叫做**执行环境**。
13 |
14 | {% hint style="info" %}
15 | **执行上下文** 为我们的可执行代码块提供了执行前的必要准备工作，例如变量对象的定义、作用域链的扩展、提供调用者的对象引用等信息。
16 | {% endhint %}
17 |
18 | ### ES3 执行上下文的类型
19 |
20 | `javascript` 中有三种执行上下文类型，分别是：
21 |
22 | * **全局执行上下文**——这是默认或者说是最基础的执行上下文，一个程序中只会存在一个全局上下文，
23 |
24 | 它在整个 `javascript` 脚本的生命周期内都会存在于执行堆栈的最底部不会被栈弹出销毁。全局上下文会生成一个全局对象（以浏览器环境为例，这个全局对象是 `window`），并且将 `this` 值绑定到这个全局对象上。
25 |
26 | * **函数执行上下文**——每当一个函数被调用时，都会创建一个新的函数执行上下文（不管这个函数是不是被重复调用的）
27 | * **Eval 函数执行上下文**—— 执行在 `eval` 函数内部的代码也会有它属于自己的执行上下文，但由于并不经常使用 `eval`，所以在这里不做分析。
28 |
29 | ### ES3 执行上下文的内容
30 |
31 | 执行上下文是一个抽象的概念，我们可以将它理解为一个 `object` ，一个执行上下文里包括以下内容：
32 |
33 | 1. 变量对象
34 | 2. 活动对象
35 | 3. 作用域链
36 | 4. 调用者信息
37 |
38 | #### 变量对象（`variable object` 简称 `VO`）
39 |
40 | > 原文：Every execution context has associated with it a variable object. Variables and functions declared in the source text are added as properties of the variable object. For function code, parameters are added as properties of the variable object.
41 |
42 | 每个执行环境文都有一个表示变量的对象——**变量对象**，全局执行环境的变量对象始终存在，而函数这样局部环境的变量，只会在函数执行的过程中存在，在函数被调用时且在具体的函数代码运行之前，JS 引擎会用当前函数的**参数列表**（`arguments`）初始化一个 “变量对象” 并将当前执行上下文与之关联 ，函数代码块中声明的 **变量** 和 **函数** 将作为属性添加到这个变量对象上。
43 |
44 | 
45 |
46 | {% hint style="warning" %}
47 | 有一点需要注意，只有**函数声明**（`function declaration`）会被加入到变量对象中，而**函数表达式**（`function expression`）会被忽略。
48 | {% endhint %}
49 |
50 | ```javascript
51 | // 这种叫做函数声明，会被加入变量对象
52 | function a () {}
53 |
54 | // b 是变量声明，也会被加入变量对象，但是作为一个函数表达式 _b 不会被加入变量对象
55 | var b = function _b () {}
56 | ```
57 |
58 | {% hint style="info" %}
59 | 全局执行上下文和函数执行上下文中的变量对象还略有不同，它们之间的差别简单来说：
60 |
61 | 1. **全局上下文中的变量对象就是全局对象**，以浏览器环境来说，就是 `window` 对象。
62 | 2. **函数执行上下文中的变量对象内部定义的属性，是不能被直接访问的**，只有当函数被调用时，变量对象（VO）被激活为活动对象（AO）时，我们才能访问到其中的属性和方法。
63 | {% endhint %}
64 |
65 | #### 活动对象（`activation object` 简称 `AO`）
66 |
67 | > 原文：When control enters an execution context for function code, an object called the activation object is created and associated with the execution context. The activation object is initialised with a property with name arguments and attributes { DontDelete }. The initial value of this property is the arguments object described below. The activation object is then used as the variable object for the purposes of variable instantiation.
68 |
69 | 函数进入执行阶段时，原本不能访问的变量对象被激活成为一个活动对象，自此，我们可以访问到其中的各种属性。
70 |
71 | {% hint style="info" %}
72 | 其实变量对象和活动对象是一个东西，只不过处于不同的状态和阶段而已。
73 | {% endhint %}
74 |
75 | #### 作用域链（`scope chain`）
76 |
77 | {% hint style="info" %}
78 | **作用域** 规定了如何查找变量，也就是确定当前执行代码对变量的访问权限。当查找变量的时候，会先从当前上下文的变量对象中查找，如果没有找到，就会从父级（词法层面上的父级）执行上下文的变量对象中查找，一直找到全局上下文的变量对象，也就是全局对象。这样由多个执行上下文的变量对象构成的链表就叫做 **作用域链**。
79 | {% endhint %}
80 |
81 | 函数的作用域在函数创建时就已经确定了。当函数创建时，会有一个名为 `[[scope]]` 的内部属性保存所有父变量对象到其中。当函数执行时，会创建一个执行环境，然后通过复制函数的 `[[scope]]` 属性中的对象构建起执行环境的作用域链，然后，变量对象 `VO` 被激活生成 `AO` 并添加到作用域链的前端，完整作用域链创建完成：
82 |
83 | ```javascript
84 | Scope = [AO].concat([[Scope]]);
85 | ```
86 |
87 | #### 当前可执行代码块的调用者（this）
88 |
89 | 如果当前函数被作为对象方法调用或使用 `bind` `call` `apply` 等 `API` 进行委托调用，则将当前代码块的调用者信息（`this value`）存入当前执行上下文，否则默认为全局对象调用。
90 |
91 | {% hint style="info" %}
92 | 关于 `this` 的创建细节，有点烦，有兴趣的话可以进入 [传送门](https://github.com/mqyqingfeng/Blog/issues/7) 学习。
93 | {% endhint %}
94 |
95 | #### 执行上下文数据结构模拟
96 |
97 | 如果将上述一个完整的执行上下文使用代码形式表现出来的话，应该类似于下面这种：
98 |
99 | ```javascript
100 | executionContext：{
101 | [variable object | activation object]：{
102 | arguments,
103 | variables: [...],
104 | funcions: [...]
105 | },
106 | scope chain: variable object + all parents scopes
107 | thisValue: context object
108 | }
109 | ```
110 |
111 | ### ES3 执行上下文的生命周期
112 |
113 | 执行上下文的生命周期有三个阶段，分别是：
114 |
115 | * 创建阶段
116 | * 执行阶段
117 | * 销毁阶段
118 |
119 | #### 创建阶段
120 |
121 | 函数执行上下文的创建阶段，发生在函数调用时且在执行函数体内的具体代码之前，在创建阶段，JS 引擎会做如下操作：
122 |
123 | * 用当前函数的**参数列表**（`arguments`）初始化一个 “变量对象” 并将当前执行上下文与之关联 ，函数代码块中声明的 **变量** 和 **函数** 将作为属性添加到这个变量对象上。**在这一阶段，会进行变量和函数的初始化声明，变量统一定义为 `undefined` 需要等到赋值时才会有确值，而函数则会直接定义**。
124 |
125 |
126 |
127 | > 有没有发现这段加粗的描述非常熟悉？没错，这个操作就是 **变量声明提升**（变量和函数声明都会提升，但是函数提升更靠前）。
128 |
129 | * 构建作用域链（前面已经说过构建细节）
130 | * 确定 `this` 的值
131 |
132 | #### 执行阶段
133 |
134 | 执行阶段中，JS 代码开始逐条执行，在这个阶段，JS 引擎开始对定义的变量赋值、开始顺着作用域链访问变量、如果内部有函数调用就创建一个新的执行上下文压入执行栈并把控制权交出……
135 |
136 | #### 销毁阶段
137 |
138 | 一般来讲当函数执行完成后，当前执行上下文（局部环境）会被弹出执行上下文栈并且销毁，控制权被重新交给执行栈上一层的执行上下文。
139 |
140 | {% hint style="warning" %}
141 | 注意这只是一般情况，闭包的情况又有所不同。
142 | {% endhint %}
143 |
144 | 闭包的定义：**有权访问另一个函数内部变量的函数。**简单说来，如果一个函数被作为另一个函数的返回值，并在外部被引用，那么这个函数就被称为闭包。
145 |
146 | ```javascript
147 | function funcFactory () {
148 | var a = 1;
149 | return function () {
150 | alert(a);
151 | }
152 | }
153 |
154 | // 闭包
155 | var sayA = funcFactory();
156 | sayA();
157 | ```
158 |
159 | 当闭包的父包裹函数执行完成后，父函数本身执行环境的作用域链会被销毁，但是由于闭包的作用域链仍然在引用父函数的变量对象，导致了父函数的变量对象会一直驻存于内存，无法销毁，除非闭包的引用被销毁，闭包不再引用父函数的变量对象，这块内存才能被释放掉。过度使用闭包会造成 **内存泄露** 的问题，这块等到闭包章节再做详细分析。
160 |
161 | ### ES3 执行上下文总结
162 |
163 | 对于 `ES3` 中的执行上下文，我们可以用下面这个列表来概括程序执行的整个过程：
164 |
165 | 1. 函数被调用
166 | 2. 在执行具体的函数代码之前，创建了执行上下文
167 | 3. 进入执行上下文的创建阶段：
168 | 1. 初始化作用域链
169 | 2. 创建 `arguments object` 检查上下文中的参数，初始化名称和值并创建引用副本
170 | 3. 扫描上下文找到所有函数声明：
171 | 1. 对于每个找到的函数，用它们的原生函数名，在变量对象中创建一个属性，该属性里存放的是一个指向实际内存地址的指针
172 | 2. 如果函数名称已经存在了，属性的引用指针将会被覆盖
173 | 4. 扫描上下文找到所有 `var` 的变量声明：
174 | 1. 对于每个找到的变量声明，用它们的原生变量名，在变量对象中创建一个属性，并且使用 `undefined` 来初始化
175 | 2. 如果变量名作为属性在变量对象中已存在，则不做任何处理并接着扫描
176 | 5. 确定 `this` 值
177 | 4. 进入执行上下文的执行阶段：
178 | 1. 在上下文中运行/解释函数代码，并在代码逐行执行时分配变量值。
179 |
180 | ### ES5 中的执行上下文
181 |
182 | `ES5` 规范又对 `ES3` 中执行上下文的部分概念做了调整，最主要的调整，就是去除了 `ES3` 中变量对象和活动对象，以 **词法环境组件（** **`LexicalEnvironment component`）** 和 **变量环境组件（** **`VariableEnvironment component`）** 替代。所以 `ES5` 的执行上下文概念上表示大概如下：
183 |
184 | ```javascript
185 | ExecutionContext = {
186 | ThisBinding = ,
187 | LexicalEnvironment = { ... },
188 | VariableEnvironment = { ... },
189 | }
190 | ```
191 |
192 | ### ES5 中的词法环境
193 |
194 | [ES6 官方](http://ecma-international.org/ecma-262/6.0/) 中的词法环境定义：
195 |
196 | > **词法环境**是一种规范类型，基于 ECMAScript 代码的词法嵌套结构来定义**标识符**和具体变量和函数的关联。一个词法环境由环境记录器和一个可能的引用**外部词法环境**的空值组成。
197 |
198 | 简单来说 **词法环境** 是一种持有 **标识符—变量映射** 的结构。这里的 **标识符** 指的是变量/函数的名字，而 **变量** 是对实际对象（包含函数类型对象）或原始数据的引用。
199 |
200 | {% hint style="info" %}
201 | 这块看不懂没关系，你可以把它理解为 `ES3` 中的 **变量对象**，因为它们本质上做的是类似的事情，这里只是先把官方给出的定义放上来。这块概念比较烦：词法环境还分为两种，然后内部有个环境记录器还分两种，，这些概念在后面会用列表的形式归纳整理出来详细说明。
202 | {% endhint %}
203 |
204 | ### ES5 中的变量环境
205 |
206 | **变量环境** 它也是一个 **词法环境** ，所以它有着词法环境的所有特性。
207 |
208 | 之所以在 `ES5` 的规范力要单独分出一个变量环境的概念是为 `ES6` 服务的： 在 `ES6` 中，**词法环境**组件和 **变量环境** 的一个不同就是前者被用来存储函数声明和变量（`let` 和 `const`）绑定，而后者只用来存储 `var` 变量绑定。
209 |
210 | {% hint style="info" %}
211 | 在上下文创建阶段，引擎检查代码找出变量和函数声明，变量最初会设置为 `undefined`（`var` 情况下），或者未初始化（`let` 和 `const` 情况下）。这就是为什么你可以在声明之前访问 `var` 定义的变量（虽然是 `undefined`），但是在声明之前访问 `let` 和 `const` 的变量会得到一个引用错误。
212 | {% endhint %}
213 |
214 | ### ES5 执行上下文总结
215 |
216 | 对于 `ES5` 中的执行上下文，我们可以用下面这个列表来概括程序执行的整个过程：
217 |
218 | 1. 程序启动，全局上下文被创建
219 | 1. 创建全局上下文的 **词法环境**
220 | 1. 创建 **对象环境记录器** ，它用来定义出现在 **全局上下文** 中的变量和函数的关系（负责处理 `let` 和 `const` 定义的变量）
221 | 2. 创建 **外部环境引用**，值为 **`null`**
222 | 2. 创建全局上下文的 **变量环境**
223 | 1. 创建 **对象环境记录器**，它持有 **变量声明语句** 在执行上下文中创建的绑定关系（负责处理 `var` 定义的变量，初始值为 `undefined` 造成声明提升）
224 | 2. 创建 **外部环境引用**，值为 **`null`**
225 | 3. 确定 `this` 值为全局对象（以浏览器为例，就是 `window` ）
226 | 2. ****函数被调用，函数上下文被创建
227 | 1. 创建函数上下文的 **词法环境**
228 | 1. 创建 **声明式环境记录器** ，存储变量、函数和参数，它包含了一个传递给函数的 **`arguments`** 对象（此对象存储索引和参数的映射）和传递给函数的参数的 **length**。（负责处理 `let` 和 `const` 定义的变量）
229 | 2. 创建 **外部环境引用**，值为全局对象，或者为父级词法环境（作用域）
230 | 2. 创建函数上下文的 **变量环境**
231 | 1. 创建 **声明式环境记录器** ，存储变量、函数和参数，它包含了一个传递给函数的 **`arguments`** 对象（此对象存储索引和参数的映射）和传递给函数的参数的 **length**。（负责处理 `var` 定义的变量，初始值为 `undefined` 造成声明提升）
232 | 2. 创建 **外部环境引用**，值为全局对象，或者为父级词法环境（作用域）
233 | 3. 确定 `this` 值
234 | 3. 进入函数执行上下文的执行阶段：
235 | 1. 在上下文中运行/解释函数代码，并在代码逐行执行时分配变量值。
236 |
237 | {% hint style="info" %}
238 | 关于 `ES5` 中执行上下文的变更，个人感觉就是变了个概念，本质和 `ES3` 差别并不大。至于变更的目的，应该是为了 `ES6` 中的 `let` 和 `const` 服务的。
239 | {% endhint %}
240 |
241 | ### 执行上下文栈
242 |
243 | 当一段脚本运行起来的时候，可能会调用很多函数并产生很多函数执行上下文，那么问题来了，这些执行上下文该怎么管理呢？为了解决这个问题，`javascript` 引擎就创建了 “执行上下文栈” （`Execution context stack` 简称 `ECS`）来管理执行上下文。
244 |
245 | 顾名思义，执行上下文栈是栈结构的，因此遵循 `LIFO`（后进先出）的特性，代码执行期间创建的所有执行上下文，都会交给执行上下文栈进行管理。
246 |
247 | 当 JS 引擎开始解析脚本代码时，会首先创建一个**全局执行上下文**，压入栈底（这个全局执行上下文从创建一直到程序销毁，都会存在于栈的底部）。
248 |
249 | 每当引擎发现一处函数调用，就会创建一个新的**函数执行上下文**压入栈内，并将控制权交给该上下文，待函数执行完成后，即将该执行上下文从栈内弹出销毁，将控制权重新给到栈内上一个执行上下文。
250 |
251 | 
252 |
253 | ### 递归和栈溢出
254 |
255 | 在了解了调用栈的运行机制后，我们可以考虑一个问题，这个执行上下文栈可以被无限压栈吗？很显然是不行的，执行栈本身也是有容量限制的，当执行栈内部的执行上下文对象积压到一定程度如果继续积压，就会报 “栈溢出（`stack overflow`）” 的错误。栈溢出错误经常会发生在 **递归** 中。
256 |
257 | 
258 |
259 | {% hint style="info" %}
260 | 程序调用自身的编程技巧称为**递归（ `recursion`）**。
261 | {% endhint %}
262 |
263 | 递归的使用场景，通常是在运行次数未知的情况下，程序会设定一个限定条件，除非达到该限定条件否则程序将一直调用自身运行下去。递归的适用场景非常广泛，比如累加函数：
264 |
265 | ```javascript
266 | // 求 1~num 的累加，此时 num 由外部传入，是未知的
267 | function recursion (num) {
268 | if (num === 0) return num;
269 | return recursion(num - 1) + num;
270 | }
271 |
272 | recursion(100) // => 5050
273 | recursion(1000) // => 500500
274 | recursion(10000) // => 50005000
275 | recursion(100000) // => Uncaught RangeError: Maximum call stack size exceeded
276 | ```
277 |
278 | 从代码中可以看到，这个递归的累加函数，在计算 1 ~ 100000 的累加和的时候，执行栈就崩不住了，触发了栈溢出的错误。
279 |
280 | ### 尾递归优化
281 |
282 | 针对递归存在的 “爆栈” 问题，我们可以学习一下 **尾递归优化**。“递归” 我们已经了解了，那么 “尾” 是什么意思呢？“尾” 的意思是 “尾调用（`Tail Call`）”，即**函数的最后一步是返回一个函数的运行结果：**
283 |
284 | ```javascript
285 | // 尾调用正确示范1
286 | function a(x){
287 | return b(x);
288 | }
289 |
290 | // 尾调用正确示范2
291 | // 尾调用不一定要写在函数的最后为止，只要保证执行时是最后一部操作就行了。
292 | function c(x) {
293 | if (x > 0) {
294 | return d(x);
295 | }
296 | return e(x);
297 | }
298 | ```
299 |
300 | 尾调用之所以与其他调用不同，就在于它的特殊的调用位置。尾调用由于是函数的最后一步操作，所以不需要保留外层函数的相关信息，因为调用位置、内部变量等信息都不会再用到了，只要直接用内层函数的调用记录，取代外层函数的调用记录就可以了，这样一来，运行尾递归函数时，执行栈永远只会新增一个上下文。
301 |
302 | 我们可以使用尾调用的方式改写下上面的累加递归：
303 |
304 | ```javascript
305 | // 尾递归优化
306 | function recursion (num, sum = 0) {
307 | if (num === 0) return sum;
308 | return recursion(num - 1, sum + num);
309 | }
310 |
311 | recursion(100000) // => Uncaught RangeError: Maximum call stack size exceeded
312 | ```
313 |
314 | 
315 |
316 | 运行之后怎么还是报错了 😳 ？？裂开了呀。。。
317 |
318 | 其实，尾递归优化这种东西，~~现在没有任何一个浏览器是支持的~~（据说 Safari 13 是支持的），`babel` 编译也不支持。那 `nodejs` 里的 `V8` 引擎呢？它做好了，但是不给你用，官方回答如下：
319 |
320 | > Proper tail calls have been implemented but not yet shipped given that a change to the feature is currently under discussion at TC39.
321 |
322 | 理由呢，它也很有道理：
323 |
324 | * 有可能由于开发者水平原因，自己写的尾递归是死循环，然后引擎层面它优化掉了，又不报错，就裂开。
325 | * 堆栈信息会在优化的过程中丢失，开发者调试非常困难，就很烦。
326 |
327 | 总之，尾递归优化这个东西暂时还是不要想用到了，不过先了解个概念也是好的。
328 |
329 | ### 小试牛刀
330 |
331 | 在网上找了几条执行上下文比较典型的面试题，大家可以试一试：
332 |
333 | **第一题：**
334 |
335 | ```javascript
336 | var foo = function () {
337 | console.log('foo1');
338 | }
339 |
340 | foo();
341 |
342 | var foo = function () {
343 | console.log('foo2');
344 | }
345 |
346 | foo();
347 | ```
348 |
349 | 第一题没什么，应该能写出来。
350 |
351 | **第二题：**
352 |
353 | ```javascript
354 | foo();
355 |
356 | var foo = function foo() {
357 | console.log('foo1');
358 | }
359 |
360 | function foo() {
361 | console.log('foo2');
362 | }
363 |
364 | foo();
365 | ```
366 |
367 | 全局执行环境自动创建，过程中生成了变量对象进行函数变量的属性收集，造成了函数声明提升、变量声明提升。由于函数声明提升更加靠前，且如果 `var` 定义变量的时候发现已有同名函数定义则跳过变量定义，上面的代码其实可以写成下面这样：
368 |
369 | ```javascript
370 | function foo () {
371 | console.log('foo2');
372 | }
373 |
374 | foo();
375 |
376 | foo = function foo() {
377 | console.log('foo1');
378 | };
379 |
380 | foo();
381 | ```
382 |
383 | **第三题：**
384 |
385 | ```javascript
386 | var foo = 1;
387 | function bar () {
388 | console.log(foo);
389 | var foo = 10;
390 | console.log(foo);
391 | }
392 |
393 | bar();
394 | ```
395 |
396 | `bar` 函数运行，内部变量申明提升，当执行代码块中有访问变量时，**先查找本地作用域**，找到了 `foo` 为 `undefined` ，打印出来。然后 `foo` 被赋值为 `10` ，打印出 `10`。
397 |
398 | **第四题：**
399 |
400 | ```javascript
401 | var foo = 1;
402 | function bar () {
403 | console.log(foo);
404 | foo = 2;
405 | }
406 | bar();
407 | console.log(foo);
408 | ```
409 |
410 | 这题也是考察的作用域链查找，`bar` 里操作的 `foo` 本地没有定义，所以应该是上层作用域的变量。
411 |
412 | **第五题：**
413 |
414 | ```javascript
415 | var foo = 1;
416 | function bar (foo) {
417 | console.log(foo);
418 | foo = 234;
419 | }
420 | bar(123);
421 | console.log(foo);
422 | ```
423 |
424 | 运行 `bar` 函数的时候将 `123` 数字作为实参传入，所以操作的还是本地作用域的 `foo`。
425 |
426 | **第六题：**
427 |
428 | ```javascript
429 | var a = 1;
430 |
431 | function foo () {
432 | var a = 2;
433 | return function () {
434 | console.log(a);
435 | }
436 | }
437 |
438 | var bar = foo();
439 | bar();
440 | ```
441 |
442 | 这道题目主要考察闭包和函数作用域的概念，我们只要记住：**函数能够访问到的上层作用域，是在函数声明时候就已经确定了的，函数声明在哪里，上层作用域就在哪里，和拿到哪里执行没有关系**。这道题目中，匿名函数被作为闭包返回并在外部调用，但它内部的作用域链引用到了父函数的变量对象中的 `a` ，所以作用域链查找时，打印出来的是 `2`。
443 |
444 | **第七题：**
445 |
446 | ```javascript
447 | var a = 1;
448 |
449 | function foo () {
450 | var a = 2;
451 | return function () {
452 | console.log(this.a);
453 | }
454 | }
455 |
456 | var bar = foo().bind(this);
457 | bar();
458 | ```
459 |
460 | 这题考察的是执行环境中的 `this` 指向的问题，由于闭包内明确指定访问 `this` 中的 `a` 属性，并且闭包被 `bind` 绑定在全局环境下运行，所以打印出的是全局对象中的 `a`。
461 |
462 | ### 总结
463 |
464 | * 当函数运行的时候，会生成一个叫做 “执行上下文” 的东西，也可以叫做执行环境，它用于保存函数运行时需要的一些信息。
465 | * 所有的执行上下文都会被交给系统的 “执行上下文栈” 来管理，它是一个栈结构数据，全局上下文永远在该栈的最底部，每当一个函数执行生成了新的上下文，该上下文对象就会被压入栈，但是上下文栈有容量限制，如果超出容量就会栈溢出。
466 | * 执行上下文内部存储了包括：**变量对象**、**作用域链**、**this 指向** 这些函数运行时的必须数据。
467 | * 变量对象构建的过程中会触发变量和函数的声明提升。
468 | * 函数内部代码执行时，会先访问本地的变量对象去尝试获取变量，找不到的话就会攀爬作用域链层层寻找，找到目标变量则返回，找不到则 `undefined`。
469 | * 一个函数能够访问到的上层作用域，在函数创建的时候就已经被确定且保存在函数的 `[[scope]]` 属性里，和函数拿到哪里去执行没有关系。
470 | * 一个函数调用时的 `this` 指向，取决于它的调用者，通常有以下几种方式可以改变函数的 `this` 值：对象调用、`call`、`bind`、`apply`。
471 |
472 | ### 相关参考
473 |
474 | * [JavaScript 深入之执行上下文](https://github.com/mqyqingfeng/Blog/issues/4)
475 | * [JavaScript深入之变量对象](https://github.com/mqyqingfeng/Blog/issues/5)
476 | * [What is the execution context in javascript](http://davidshariff.com/blog/what-is-the-execution-context-in-javascript/)
477 | * [Understanding Execution Context and Execution Stack in Javascript](https://blog.bitsrc.io/understanding-execution-context-and-execution-stack-in-javascript-1c9ea8642dd0)
478 | * \*\*\*\*[图解Javascript——变量对象和活动对象](https://www.cnblogs.com/ivehd/p/vo_ao.html)
479 | * [\[译\] 理解 JavaScript 中的执行上下文和执行栈](https://juejin.im/post/5ba32171f265da0ab719a6d7#heading-1)
480 | * [理解Javascript之执行上下文\(Execution Context**\)**](https://www.cnblogs.com/MinLee/p/5862271.html)\*\*\*\*
481 | * [知乎：JS中的作用域链是在什么时候建立的？](https://www.zhihu.com/question/36751764)
482 | * [VO、AO、执行环境和作用域链](https://www.cnblogs.com/lulin1/p/9712311.html)
483 | * [尾调用优化](http://www.ruanyifeng.com/blog/2015/04/tail-call.html)
484 | * [JavaScript调用栈、尾递归和手动优化](https://www.jianshu.com/p/3182429e26b5)
485 |
486 |
--------------------------------------------------------------------------------
/javascript-basics/javascript-basics.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: javascript 基础部分
3 | ---
4 |
5 | # javascript 基础
6 |
7 | 1. 七个基本类型：String Number Boolean BigInt undefined null Symbol
8 | 2. 引用类型：Function Array Object
9 | 3. typeof 除了 null 是 object 能够识别其他基本类型
10 | 4. instanceof 原理是通过原型链来判断类型，因此只能判断引用类型，对基本类型值无效
11 | 5. this 的绑定优先级：new -> bind/apply -> obj.func\(\) -> func\(\)
12 | 6. bind 只有在第一次的时候绑定的 this 有效
13 | 7. 箭头函数没有自己的 this 需要依赖父作用域中的 this
14 | 8. 深拷贝方法：
15 | * JSON.parse\(JSON.stringify\(\)\)
16 | * MessageChannel
17 | * 自己写一个
18 | 9. JSON.parse\(JSON.stringify\(\)\)深拷贝的问题：
19 | * 会忽略 undefined、function、Symbol
20 | * 对象内部有循环引用会报错
21 | 10. MessageChannel 深拷贝问题：可以正确复制 undefined 以及循环引用，但是函数和 Symbol 属性还是会报错
22 | 11. MessageChannel 实现的深拷贝：
23 |
24 | ```javascript
25 | function structuralClone(obj) {
26 | return new Promise((resolve, reject) => {
27 | const {port1, port2} = new MessageChannel();
28 | port1.onmessage = ev => resolve(ev.data);
29 | port2.postMessage(obj);
30 | })
31 | }
32 |
33 | var obj = {
34 | a: 1,
35 | c: {
36 | d: undefined,
37 | e: 'helo world'
38 | }
39 | }
40 |
41 | const test = async () => {
42 | const clone = await structuralClone(obj)
43 | console.log(clone)
44 | }
45 | test()
46 | ```
47 |
48 | 12. 手写一个简单的深拷贝
49 |
50 | ```javascript
51 | function deepClone (obj) {
52 | function isObject (obj) {
53 | const type = typeof obj;
54 | return (type === 'object' && obj != null) || type === 'function'
55 | }
56 |
57 | if (!isObject) throw new Error('非对象')
58 |
59 | const isArray = Array.isArray(obj);
60 | const isFunction = typeof obj === 'function';
61 | let newObj = isArray ? [...obj] : isFunction ? obj : {...obj}
62 | Reflect.ownKeys(newObj).forEach(key => {
63 | newObj[key] = isObject(newObj[key]) ? deepClone(newObj[key]) : newObj[key]
64 | })
65 |
66 | return newObj
67 | }
68 | ```
69 |
70 |
--------------------------------------------------------------------------------
/javascript-basics/javascript-type-transform.md:
--------------------------------------------------------------------------------
1 | # javascript 类型转换
2 |
3 | ### 关于 JS 类型转换
4 |
5 | JS 有六种基本数据类型：
6 |
7 | * `number`
8 | * `string`
9 | * `boolean`
10 | * `undefined`
11 | * `null`
12 | * `symbol`\(`ES6` 新加入\)
13 |
14 | 以及一种引用类型：
15 |
16 | * `object`
17 |
18 | 当这些不同类型的数据之间，需要通过逻辑操作符进行判断，或者进行运算操作时，就会触发 JS 的隐性类型转换机制，对不同类型的数据先进行转换操作，再运行相关逻辑。
19 |
20 | ### 类型转换规则
21 |
22 | JS 种的类型转换，只有如下三种情况：
23 |
24 | * 转为布尔值
25 | * 转为数字
26 | * 转为字符串
27 |
28 | 以下是各种数据类型之间相互转换的表格：
29 |
30 | | 原始值类型 | 目标值类型 | 结果 |
31 | | :---: | :---: | :---: |
32 | | boolean | 布尔值 | 本身值，false 就为 false ，true 就为 true |
33 | | number | 布尔值 | 0 和 NaN 为 false 否则都为 true |
34 | | string | 布尔值 | 除了空字符串为 false 其他都为 true |
35 | | undefined、null | 布尔值 | false |
36 | | symbol | 布尔值 | true |
37 | | 对象 | 布尔值 | true |
38 | | 数组 | 布尔值 | true |
39 |
40 | | 原始值类型 | 目标值类型 | 结果 |
41 | | :---: | :---: | :---: |
42 | | boolean | 字符串 | true: 'true'；false: 'false' |
43 | | number | 字符串 | 数字字符串 |
44 | | string | 字符串 | 字符串本身值 |
45 | | undefined、null | 字符串 | 抛错 |
46 | | symbol | 字符串 | symbol 字符串 |
47 | | 对象 | 字符串 | '\[object Object\]' |
48 | | 数组 | 字符串 | 空数组转为空字符串，否则转为由逗号拼接每一项的字符串 |
49 |
50 | | 原始值类型 | 目标值类型 | 结果 |
51 | | :---: | :---: | :---: |
52 | | boolean | 数字 | true 转换为 1，false 转换为 0 |
53 | | number | 数字 | 数字本身 |
54 | | string | 数字 | 除了都是数字组成的字符串，能转换成数字外，其他都是 NaN |
55 | | null | 数字 | 0 |
56 | | undefined | 数字 | NaN |
57 | | symbol | 数字 | 抛错 |
58 | | 对象 | 数字 | NaN |
59 | | 数组 | 数字 | 空数组转换为0；只有一项（数字）的数组转换为这个数字；只有一项（空字符串、undefined、null）的数组转换为0；除上述以外情况的数组转换为 `NaN` |
60 |
61 | ### 触发 JS 隐式转换的先决条件
62 |
63 | 在下面两种情况下，将会触发 JS 的隐性类型转换机制。 1. 当使用 `==`、`&&`、`||` 等逻辑操作符进行判断时 2. 当使用 `+ - * /` 四则运算符进行操作时
64 |
65 | 下面就 `==` 和四则运算两种情况，来分析一下内部的转化机制:
66 |
67 | #### 1. 使用 `==` 操作符进行判断时
68 |
69 | 先来看下在使用 `==` 进行判断时，隐式转换的内部机制，判断步骤如下：
70 |
71 | **两个操作数类型一样的情况：**
72 |
73 | 1. 如果两个操作数是同类基本类型值，则直接比较
74 | 2. 如果两个操作数是同类引用类型值，则比较内存地址
75 |
76 | **两个操作数类型不一样的情况：**
77 |
78 | 3. 如果有一个操作数是布尔值，则将这个布尔值转换为数字再进行比较。
79 | 4. 如果有一个操作数是字符串，另一个操作数是数字，则将字符串转换成数字再进行比较
80 | 5. 如果有一个操作数是引用类型的值，则调用该实例的 `valueOf` 方法，如果得到的值不是基本类型的值，再调用该实例的 `toString` 方法，用得到的基本类型的值按照前面的规则进行匹配对比。
81 |
82 | 以上逻辑转换成流程图：
83 |
84 | 
85 |
86 | **特殊情况：**
87 |
88 | 1. `null == undefined` 判断为 `true`
89 | 2. `null` 和 `undefined` 无法转换为基本类型值
90 | 3. `NaN != NaN` 判断为 `true`，事实上，`NaN` 更像一个特例，谁都不等于
91 |
92 | #### 2. 使用 `+` 进行判断时
93 |
94 | 1. 两个操作数都为数字时直接运行加法操作
95 | 2. 若有一方为字符串，则将两个操作数都转换成字符串，进行字符串拼接操作。
96 | 3. `true + true` / `false + false` / `null + null` 转换为数字进行加法运算
97 | 4. `undefined + undefined` 进行加法运算，结果为 `NaN`
98 |
99 | **3. 使用除 + 号以外的四则运算符判断时**
100 |
101 | 直接进行数学运算，行就行，不行就直接 `NaN`，简单粗暴。
102 |
103 | ### 类型转换的经典面试题目
104 |
105 | 1. `[] == ![]` 输出结果是？
106 | 2. `{} == !{}` 输出结果是？
107 | 3. `1 + '1'` 输出结果是？
108 | 4. `true + true` 输出结果是？
109 | 5. `4 + []` 输出结果是？
110 | 6. `4 + {}` 输出结果是？
111 | 7. `4 + [1]` 输出结果是？
112 | 8. `4 + [1, 2, 3, 4]` 输出结果是？
113 | 9. `'a' + + 'b'`输出结果是？
114 |
115 | 第一题的转化逻辑如下：
116 |
117 | ```javascript
118 | // 尝试判断，!运算符的优先级大于 ==，所以实际上这里还涉及到!的运算。
119 | [] == ![]
120 | // 将右边 ![] 进行转换
121 | [] == false
122 | // 隐式转换布尔值为数字
123 | [] == 0
124 | // 转换左边的 []，调用 [] 实例的 valueOf 方法
125 | [] == 0
126 | // valueOf 方法返回的不是基本类型值，再次调用 toString 方法
127 | '' == 0
128 | // 隐式转换字符串为数字
129 | 0 == 0
130 | // 返回结果
131 | true
132 | ```
133 |
134 | 第二题的转化逻辑如下：
135 |
136 | ```javascript
137 | // 尝试判断，!运算符的优先级大于 ==，所以实际上这里还涉及到!的运算。
138 | {} == !{}
139 | // 将右边 !{} 进行转换
140 | {} == false
141 | // 隐式转换布尔值为数字
142 | {} == 0
143 | // 转换左边的 {}，调用 {} 实例的 valueOf 方法
144 | {} == 0
145 | // valueOf 方法返回的不是基本类型值，再次调用 toString 方法
146 | '[object Object]' == 0
147 | // 隐式转换字符串为数字
148 | NaN == 0
149 | // 返回结果
150 | false
151 | ```
152 |
153 | 后面的题目：
154 |
155 | ```javascript
156 | // 第三题
157 | 1 + '1' == '1' + '1' == '11'
158 | // 第四题
159 | true + true == 1 + 1 == 2
160 | // 第五题
161 | 4 + [] == '4' + '' == '4'
162 | // 第六题
163 | 4 + {} == '4' + '[object Object]' == '4[object Object]'
164 | // 第七题
165 | 4 + [1] == '4' + '1' == '41'
166 | // 第八题
167 | 4 + [1, 2, 3, 4] == '4' + '1, 2, 3, 4' == '41,2,3,4'
168 | // 第九题，稍微有点复杂，+'b'是被转换成了 NaN
169 | 'a' + + 'b' == 'a' + 'NaN' == 'aNaN'
170 | ```
171 |
172 | > 本文参考了一些别人的观点，再加上自己手动控制台打印认证，如果有错误，欢迎指出，我即时修改。
173 |
174 |
--------------------------------------------------------------------------------
/javascript-basics/modularization.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | 一门语言发展壮大的毕竟之路就是模块化的出现，很多语言天生设计中就带有这一特性，可惜的是 JS 从一开始就不是天生支持模块化的，变量污染和命名冲突问题让众多
4 | js 开发者不得不寻求一种实现 js 模块化的方法。从最初的自执行函数，到 AMD / CMD ，再到后来的 Commonjs 规范，以及 ES6 中出现的
5 | ESModule，语言的发展让我们可以选择不同的模块化技术来应对的不同场景。
6 | ---
7 |
8 | # 模块化
9 |
10 | ### 为什么使用模块化？
11 |
12 | * 解决变量间相互污染的问题，以及变量命名冲突的问题
13 | * 提高代码的可维护性、可拓展性和复用性
14 |
15 | ### 自执行函数实现的模块化
16 |
17 | 自执行函数实现模块化的方法非常简单：
18 |
19 | ```javascript
20 | // 自执行函数实现模块化
21 | (function () {
22 | var a = 1;
23 | console.log(a); // 1
24 | })();
25 |
26 | (function () {
27 | var a = 2;
28 | console.log(a); // 2
29 | })();
30 | ```
31 |
32 | 自执行函数本质上是通过函数作用域解决了命名冲突、污染全局作用域的问题。
33 |
34 | ### AMD 、CMD 和 UMD
35 |
36 | {% hint style="info" %}
37 | [AMD](https://github.com/amdjs/amdjs-api/wiki/AMD) 是"Asynchronous Module Definition"的缩写，意思就是"异步模块定义" ，它采用异步方式加载模块，模块的加载不影响它后面语句的运行。所有依赖这个模块的语句，都定义在一个回调函数中，等到所有依赖项都加载完成之后，这个回调函数才会运行。
38 | {% endhint %}
39 |
40 | {% hint style="info" %}
41 | [CMD](https://github.com/seajs/seajs/issues/242) 是"Common Module Definition"的缩写，意思就是"公共模块定义"。CMD 可以使用 require 同步加载依赖，也可以使用 require.async 来异步加载依赖。
42 | {% endhint %}
43 |
44 | {% hint style="info" %}
45 | AMD 和 CMD 都是非官方的两种 js 模块化规范，AMD 标准的代表框架是 RequireJS ，CMD 标准的代表框架是 SeaJS。
46 | {% endhint %}
47 |
48 | ```javascript
49 | // AMD
50 | define(['./a', './b'], function(a, b) {
51 | // 加载模块完毕可以使用
52 | a.do();
53 | b.do();
54 | });
55 |
56 | // CMD
57 | define(function(require, exports, module) {
58 | // 加载模块
59 | // 可以把 require 写在函数体的任意地方实现延迟加载
60 | var a = require('./a');
61 | a.doSomething();
62 |
63 | // 也可以使用 require.async 来延迟加载
64 | require.async('./b', function(b) {
65 | b.doSomething();
66 | });
67 | });
68 | ```
69 |
70 | 现在 `ESModule` 和 `CommonJS` 已经分别统一了浏览器端和 Node 端的模块加载， `AMD` 和 `CMD` 使用的比较少，不过作为很多老项目使用的模块化方案，还是值得了解一下的。
71 |
72 | `AMD` 和 `CMD` 相比，很大的一个区别就是引入模块的时机，`AMD` 是前置依赖，也就是说，目标模块代码执行前，必须保证所有的依赖都被引入并且执行。`CMD` 是后置依赖，也就是说，只有在目标代码中手动执行 `require(..)` 的时候，相关依赖才会被加载并执行。
73 |
74 | 还有一个区别就是引入模块的方式，`AMD` 的定位是浏览器环境，所以是异步引入；而 `CMD` 的定位是浏览器环境和 Node 环境，它可以使用 `require` 进行同步引入，也可以使用 `require.async` 的方式进行异步引入。
75 |
76 | #### UMD
77 |
78 | 从下面的代码中不难看出，其实 `UMD` 就是一种通用的模块化方式，它将 `AMD` 和 `CMD` 以及全局注册的方式做了整合而已，我们熟悉的 `jQuery` 和很多的工具库都是使用这种模块化的方式进行引入。
79 |
80 | ```javascript
81 | // UMD
82 | (function (root, factory) {
83 | if (typeof define === 'function' && define.amd) {
84 | // AMD
85 | define(['jquery'], factory);
86 | } else if (typeof exports === 'object') {
87 | // Node, CommonJS-like
88 | module.exports = factory(require('jquery'));
89 | } else {
90 | // Browser globals (root is window)
91 | root.returnExports = factory(root.jQuery);
92 | }
93 | }(this, function ($) {
94 | // methods
95 | function myFunc(){};
96 |
97 | // exposed public method
98 | return myFunc;
99 | }));
100 | ```
101 |
102 | ### CommonJS 实现模块化
103 |
104 | {% hint style="info" %}
105 | `CommonJS` 是的 NodeJS 所使用的一种服务端的模块化规范，它将每一个文件定义为一个 `module` ，模块必须通过 `module.exports` 导出对外的变量或接口，通过 `require()` 来导入其他模块的输出到当前模块作用域中。
106 | {% endhint %}
107 |
108 | 使用方式一：
109 |
110 | ```javascript
111 | // a.js
112 | const a = 1;
113 | const func = function () {
114 | return a + 1;
115 | }
116 | // 将 func 作为一个模块导出
117 | module.exports = func;
118 |
119 |
120 | // main.js
121 | const func = require('./a.js');
122 | console.log(func());
123 | ```
124 |
125 | 使用方式二：
126 |
127 | ```javascript
128 | // a.js
129 | const a = 1;
130 | const func = function () {
131 | return a + 1;
132 | }
133 | // 将 func 作为模块的一个属性导出
134 | module.exports.func = func;
135 |
136 |
137 | // main.js
138 | const { func } = require('./a.js');
139 | console.log(func());
140 | ```
141 |
142 | 使用方式三：
143 |
144 | ```javascript
145 | // a.js
146 | const a = 1;
147 | const func = function () {
148 | return a + 1;
149 | }
150 | // 将 func 作为模块的一个属性导出，等同于上面一中写法
151 | module.exports = {
152 | func
153 | };
154 |
155 |
156 | // main.js
157 | const { func } = require('./a.js');
158 | console.log(func());
159 | ```
160 |
161 | 使用方式四：
162 |
163 | ```javascript
164 | // a.js
165 | const a = 1;
166 | const func = function () {
167 | return a + 1;
168 | }
169 | // 利用 Node 提供的便捷写法 exports 来导出模块
170 | exports.func = func;
171 |
172 |
173 | // main.js
174 | const { func } = require('./a.js');
175 | console.log(func());
176 | ```
177 |
178 | `CommonJS` 具有如下特点：
179 |
180 | * 所有代码都运行于模块作用域，不会污染全局。
181 | * 使用同步的方式加载，也就是说，只有加载完成才能执行后面的操作，这点和 `AMD` 不同，由于 `CommonJS` 的模块化是用在 Node 端也就是服务端，模块加载的时间损耗只是磁盘读取，这个加载速度是很快的，所以可以使用同步的方式。
182 | * `CommonJS` 支持动态导入的方式,，比如：``require(`./${path}.js`)``
183 | * 模块可以多次加载，但是只会在第一次加载时运行一次，然后加载结果会被缓存，后面再次加载会直接读取缓存结果，如果想让模块重新执行，就必须清除缓存。
184 | * `CommonJS` 模块输出的是一个**值的拷贝，**这一点会在下面的 ESModule 和 CommonJS 对比中详细说明。
185 | * 模块的加载顺序，按照其在代码中出现的顺序。
186 |
187 | 我们可以来模拟一个简化版 `CommonJS` 的实现：
188 |
189 | 1. 每一个模块内部都有一个 module 对象，代表当前模块，它需要具有以下属性：
190 |
191 | * `module.id` 模块的唯一标识符
192 | * `module.filename` 模块的文件名、
193 | * `module.loaded` 返回一个布尔值，代表模块是否加载完成
194 | * `module.parent` 返回一个对象，代表调用该模块的父模块
195 | * `module.children` 返回一个数组，内容为这个模块所依赖的其他模块
196 | * `module.exports` 最重要的一个，表示模块的对外输出内容
197 |
198 | ```javascript
199 | function Module (id, parent, children) {
200 | this.id = id;
201 | this.filename = 'filename.js';
202 | this.loaded = false;
203 | this.parent = parent;
204 | this.children = children;
205 | this.exports = {};
206 | // ...
207 | }
208 |
209 | const module = new Module('uuid', null, []);
210 | ```
211 |
212 | 2. `Node`会为每一个模块提供一个 export 变量，指向 `module.exports`：
213 |
214 | ```javascript
215 | function Module (id, parent, children) {
216 | this.id = id;
217 | this.filename = 'filename.js';
218 | this.loaded = false;
219 | this.parent = parent;
220 | this.children = children;
221 | this.exports = {};
222 | // ...
223 | }
224 |
225 | const module = new Module('uuid', null, []);
226 | let exports = module.exports;
227 | ```
228 |
229 | 3. 模块开发者向外部导入数据：
230 |
231 | ```javascript
232 | function Module (id, parent, children) {
233 | this.id = id;
234 | this.filename = 'filename.js';
235 | this.loaded = false;
236 | this.parent = parent;
237 | this.children = children;
238 | this.exports = {};
239 | // ...
240 | }
241 |
242 | const module = new Module('uuid', null, []);
243 | let exports = module.exports;
244 |
245 | module.exports = function () {
246 | console.log('module message');
247 | }
248 | ```
249 |
250 | {% hint style="warning" %}
251 | **注意：**虽然 Node 原生提供了 `exports` 作为 `module.exports` 的简化写法，但是不能手动改变 `exports` 的赋值，比如这样：`exports = {}`，这样写就代表将 `module.exports` 的引用从 `exports` 上切断了。这就意味着：如果一个模块的对外接口是一个单一的值（例如：数字、函数、字符串），就不能使用 `exports` 只能使用 `module.exports` 输出 。
252 | {% endhint %}
253 |
254 | #### 关于 require
255 |
256 | {% hint style="info" %}
257 | `CommonJS` 中 `require` 的基本功能，是读入并执行一个 JavaScript 文件，然后返回该模块的 `exports` 对象，如果没有发现指定模块则报错。
258 | {% endhint %}
259 |
260 | * require 加载文件时，默认后缀为 `.js` 后缀。
261 | * 如果 `require` 中的路径字符串参数以 `'/'` 开头，则会按照这个绝对路径查找文件。
262 | * 如果 `require` 中的路径字符串参数以 `'./'` 开头，则会以当前执行脚本位置为起点，寻找对应的相对路径下的文件。
263 | * 如果参数字符串不以 `'/'` 或者 `'./'` 开头，则会去寻找一个默认提供的核心模块（位于 Node 系统安装目录中），或者一个位于各级 `node_modules` 目录中的已安装模块（全局安装或者局部安装），举例来说，如果脚本 `'/home/user/projects/foo.js'` 执行了 `require('bar.js')` 命令，Node 会依次搜索以下文件：
264 | * `/usr/local/lib/node/bar.js`（Node 的核心模块）
265 | * `/home/user/projects/node_modules/bar.js`（当前执行脚本所在目录下的 node\_modules 文件）
266 | * `/home/user/node_modules/bar.js`（执行脚本所在目录下没有 node\_modules ，则继续查找上层文件夹的 node\_modules）
267 | * `/home/node_modules/bar.js`（继续查找上层的 node\_modules）
268 | * `/node_modules/bar.js`（最后查找全局的 node\_modules）
269 | * 如果参数字符串不以“./“或”/“开头，而且是一个路径，比如`require('example-module/path/to/file')`，则将先找到`example-module`的位置，然后再以它为参数，找到后续路径。
270 | * 如果指定的文件没有找到，Node 会为文件名添加 `.js / .json / .node` 后缀再次尝试匹配，`.json` 文件会以 JSON 格式的文本文件解析，`.node` 文件会以编译后的二进制文件解析。
271 |
272 | ### ESModule 实现的模块化
273 |
274 | {% hint style="info" %}
275 | `ESModule` 是 ES6 提供的官方 js 模块化方案。目前浏览器还不能全面支持 `ESModule` 的语法，需要用 babel 进行解析。
276 | {% endhint %}
277 |
278 | #### ESModule 常用语法
279 |
280 | 输出变量和函数接口：
281 |
282 | ```javascript
283 | // lib.js
284 | export var a = 1;
285 | // 或者 export 函数
286 | export function func () {};
287 |
288 |
289 | // main.js
290 | import { a, func } from './lib.js';
291 | ```
292 |
293 | 将内部变量函数等封装为一个对象输出：
294 |
295 | ```javascript
296 | // lib.js
297 | var a = 1;
298 | function func () {}
299 | export {a, func};
300 |
301 |
302 | // main.js
303 | import { a, func } from './lib.js';
304 | ```
305 |
306 | 将内部变量函数等改名后封装为一个对象输出：
307 |
308 | ```javascript
309 | // lib.js
310 | var a = 1;
311 | function func () {}
312 | // 改一个名字然后暴露
313 | export {a as aa, func as foo};
314 |
315 |
316 | // main.js
317 | // 注意，这边引入的时候就必须要用更改后的名字
318 | import { aa, foo} from './lib.js';
319 | ```
320 |
321 | `export` 输出变量和函数接口，然后在另一个文件中使用 `import *` 的方式接收：
322 |
323 | ```javascript
324 | // lib.js
325 | export var a = 1;
326 | // 或者 export 函数
327 | export function func () {};
328 |
329 |
330 | // main.js
331 | import * from './lib.js';
332 | console.log(a);
333 | func();
334 |
335 | // 或者这么接
336 | import * as lib from './lib.js';
337 | console.log(lib.a);
338 | lib.func();
339 |
340 | ```
341 |
342 | 怕麻烦的话，你也可以直接输出一个 `default` 默认。 `export default` 命令用于指定模块的默认输出，一个模块只能有一个默认输出，因此`export default` 命令只能使用一次。所以，`import` 命令后面不用加大括号，因为只可能唯一对应`export default` 命令：
343 |
344 | ```javascript
345 | // lib.js
346 | export default function () {
347 | console.log('Hello ESModule');
348 | }
349 |
350 |
351 | // main.js
352 | // 如果引入 default 默认值，就没有固定的名称了，叫什么都可以
353 | import foo from './lib.js';
354 | ```
355 |
356 | **需要注意！**由于 `export` 导出的必须是接口，下面的写法会报错：
357 |
358 | ```javascript
359 | // export 错误写法，因为导出的不是接口而是值
360 | var a = 1;
361 | function func () {}
362 | // 报错
363 | export a;
364 | // 报错
365 | export 1;
366 | // 报错
367 | export func;
368 | ```
369 |
370 | 但是 `export default` 例外，因为本质上，`export default` 就是输出一个叫做`default`的变量或方法，然后系统允许你为它取任意名字。所以，上面那种会报错的写法改写成 `default` 是有效的，不过注意，一个文件只能暴露一个 `default` ：
371 |
372 | ```javascript
373 | var a = 1;
374 | export default a;
375 | ```
376 |
377 | 最后，还有一种 import 和 export 结合的高级写法，传说中的模块继承，这种写法我们会在某些源码的 `main.js` 中见到：
378 |
379 | ```javascript
380 | // app.vue
381 | function vueComponent () {}
382 | export { vueComponent };
383 |
384 |
385 | // main.js
386 | export { vueComponent } from './app.vue';
387 | // 或者
388 | export { vueComponent as newVueComponent } from './app.vue';
389 | // 或者
390 | export * from './app.vue';
391 | // 或者
392 | export * as components from './app.vue';
393 | ```
394 |
395 | `default` 版本的模块继承：
396 |
397 | ```javascript
398 | // app.vue
399 | function vueComponent () {}
400 | export default vueComponent;
401 |
402 |
403 | // main.js
404 | export { default } from './app.vue';
405 | ```
406 |
407 | #### ESModule VS CommonJS
408 |
409 | `ESModule` 对比 `CommonJS` 主要有以下不同：
410 |
411 | * `CommonJS` 模块输出的是一个**值的拷贝**，`ESModule` 输出的是**值的引用**。
412 |
413 | `CommonJS` 输出的是**值的拷贝**，也就是说一旦输出，模块内部的变化就影响不到这个值
414 |
415 | ```javascript
416 | // lib.js
417 | let counter = 3;
418 | function incCounter() {
419 | counter++;
420 | }
421 | module.exports = {
422 | counter,
423 | incCounter,
424 | };
425 |
426 |
427 | // main.js
428 | let mod = require('./lib');
429 |
430 | console.log(mod.counter); // 3
431 | mod.incCounter();
432 | console.log(mod.counter); // 4
433 | ```
434 |
435 | `mod.counter`是一个原始类型的值，会被缓存。除非写成一个函数，才能得到内部变动后的值。
436 |
437 | ```javascript
438 | // lib.js
439 | let counter = 3;
440 | function incCounter() {
441 | counter++;
442 | }
443 | module.exports = {
444 | get counter: {
445 | return counter;
446 | },
447 | incCounter
448 | };
449 |
450 |
451 | // main.js
452 | let mod = require('./lib');
453 |
454 | console.log(mod.counter); // 3
455 | mod.incCounter();
456 | console.log(mod.counter); // 3
457 | ```
458 |
459 | 当然，你也可以对外暴露一个对象，`CommonJS` 导出的是对象引用的值的复制，那么这种情况 ，也是能够得到内部变动的值的。
460 |
461 | ```javascript
462 | // lib.js
463 | let obj = {a: 1};
464 | function changeA() {
465 | obj.a = 2;
466 | }
467 | module.exports = {
468 | obj,
469 | changeA
470 | };
471 |
472 |
473 | // main.js
474 | const mod = require('./lib.js');
475 | console.log(JSON.stringify(mod.obj)); // {"a":1}
476 | target.changeA();
477 | console.log(JSON.stringify(mod.obj)); // {"a":2}
478 | ```
479 |
480 | `ESModule` 输出的是**值的引用**，它不会缓存运行结果，而是动态地去被加载的模块取值，并且变量总是绑定其所在的模块：
481 |
482 | ```javascript
483 | // lib.js
484 | export let counter = 3;
485 | export function incCounter() {
486 | counter++;
487 | }
488 |
489 | // main.js
490 | import { counter, incCounter } from './lib';
491 | console.log(counter); // 3
492 | incCounter();
493 | console.log(counter); // 4
494 | ```
495 |
496 | * `ESModule` 的模块化是**静态的**，和 `CommonJS` 不同，`ESModule` 模块不是对象，而是通过 `export` 命令显示输出的指定代码的片段，再通过 `import` 命令将代码命令输入。也就是说在**编译阶段**就需要确定模块之间的依赖关系，这一点不同于 `AMD / CMD / CommonJS` ，这三者都是在**运行时**确定模块间的依赖关系的。
497 |
498 | #### ESModule 的其他细节特点
499 |
500 | * ES6 的模块自动采用严格模式，不管你有没有在模块头部加上`"use strict";`
501 | * ESModule 导出的模块是只读的，不能变更，否则报错：
502 |
503 | ```javascript
504 | // lib.js
505 | export let obj = {};
506 |
507 | // main.js
508 | import { obj } from './lib';
509 |
510 | obj.prop = 123; // OK
511 | obj = {}; // TypeError
512 | ```
513 |
514 |
515 |
516 | ### 相关参考
517 |
518 | * [JavaScript 标准参考教程](https://javascript.ruanyifeng.com/nodejs/module.html)
519 | * [前端面试之道](https://juejin.im/book/5bdc715fe51d454e755f75ef/section/5bdd0d83f265da615f76ba57#heading-6)
520 | * [ES6 Module 的语法](https://es6.ruanyifeng.com/#docs/module)
521 |
522 |
--------------------------------------------------------------------------------
/javascript-basics/prototype-chain-and-inheritance.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | JavaScript 中没有类的概念的，主要通过原型链来实现继承。通常情况下，继承意味着复制操作，然而 JavaScript
4 | 默认并不会复制对象的属性，相反，JavaScript
5 | 只是在两个对象之间创建一个关联（原型对象指针），这样，一个对象就可以通过委托访问另一个对象的属性和函数，所以与其叫继承，委托的说法反而更准确些。
6 | ---
7 |
8 | # 原型链及继承
9 |
10 | ### 原型、构造函数及原型链
11 |
12 | #### 原型
13 |
14 | {% hint style="info" %}
15 | 当我们 new 了一个新的对象实例，明明什么都没有做，就直接可以访问 toString 、valueOf 等原生方法。那么这些方法是从哪里来的呢？答案就是原型。
16 | {% endhint %}
17 |
18 | 
19 |
20 | 在控制台打印一个空对象时，我们可以看到，有很多方法，已经“初始化”挂载在内置的 `__proto__` 对象上了。这个内置的 `__proto__` 是一个指向原型对象的指针，它会在创建一个新的引用类型对象时（显示或者隐式）自动创建，并挂载到新实例上。当我们尝试访问实例对象上的某一属性 / 方法时，如果实例对象上有该属性 / 方法时，就返回实例属性 / 方法，如果没有，就去 `__proto__` 指向的原型对象上查找对应的属性 / 方法。这就是为什么我们尝试访问空对象的 `toString` 和 `valueOf` 等方法依旧能访问到的原因，**`JavaScript` 正式以这种方式为基础来实现继承的。**
21 |
22 | #### 构造函数
23 |
24 | 如果说实例的 `__proto__` 只是一个指向原型对象的指针，那就说明在此之前原型对象就已经创建了，那么原型对象是什么时候被创建的呢？这就要引入**“构造函数”**的概念。
25 |
26 | 其实构造函数也就只是一个普通的函数而已，如果这个函数可以使用 `new` 关键字来创建它的实例对象，那么我们就把这种函数称为 **构造函数**。
27 |
28 | ```javascript
29 | // 普通函数
30 | function person () {}
31 |
32 | // 构造函数，函数首字母通常大写
33 | function Person () {}
34 | const person = new Person();
35 | ```
36 |
37 | 原型对象正是在构造函数被声明时一同创建的。构造函数被申明时，原型对象也一同完成创建，然后挂载到构造函数的 `prototype` 属性上：
38 |
39 | 
40 |
41 | 原型对象被创建时，会自动生成一个 `constructor` 属性，指向创建它的构造函数。这样它俩的关系就被紧密地关联起来了。
42 |
43 | {% hint style="info" %}
44 | 细心的话，你可能会发现，原型对象也有自己的 **proto** ，这也不奇怪，毕竟万物皆对象嘛。原型对象的 **proto** 指向的是 Object.prototype。那么 Object.prototype.**proto** 存不存在呢？其实是不存在的，打印的话会发现是 null 。这也证明了 Object 是 JavaScript 中数据类型的起源。
45 | {% endhint %}
46 |
47 | 分析到这里，我们大概了解原型及构造函数的大概关系了，我们可以用一张图来表示这个关系：
48 |
49 | 
50 |
51 | #### 原型链
52 |
53 | 说完了原型，就可以来说说原型链了，如果理解了原型机制，原型链就很好解释了。其实上面一张图上，那条被 `__proto__` 链接起来的链式关系，就称为**原型链**。
54 |
55 | **原型链的作用：**原型链如此的重要的原因就在于它决定了 `JavaScript` 中继承的实现方式。当我们访问一个属性时，查找机制如下：
56 |
57 | * 访问对象实例属性，有则返回，没有就通过 `__proto__` 去它的原型对象查找。
58 | * 原型对象找到即返回，找不到，继续通过原型对象的 \_\_proto\_\_ 查找。
59 | * 一层一层一直找到 `Object.prototype` ，如果找到目标属性即返回，找不到就返回 `undefined`，不会再往下找，因为在往下找 `__proto__` 就是 `null` 了。
60 |
61 | 通过上面的解释，对于构造函数生成的实例，我们应该能了解它的原型对象了。JavaScript 中万物皆对象，那么构造函数肯定也是个对象，是对象就有 `__proto__` ，那么构造函数的 `__proto__` 是什么？
62 |
63 | 我们可以打印出来看一下：
64 |
65 | 
66 |
67 | 现在才想起来所有的函数可以使用 `new Function()` 的方式创建，那么这个答案也就很自然了，有点意思，再来试试别的构造函数。
68 |
69 | 
70 |
71 | 这也证明了，所有函数都是 `Function` 的实例。等一下，好像有哪里不对，那么 `Function.__proto__` 岂不是。。。
72 |
73 | 
74 |
75 | 
76 |
77 | 按照上面的逻辑，这样说的话，`Function` 岂不是自己生成了自己？其实，我们大可不必这样理解，因为作为一个 JS 内置对象，`Function` 对象在你脚本文件都还没生成的时候就已经存在了，哪里能自己调用自己，这个东西就类似于玄学中的“道”和“乾坤”，你能说明它们是谁生成的吗，天地同寿日月同庚不生不灭。。。算了，在往下扯就要写成修仙=。=
78 |
79 | 至于为什么 `Function.__proto__` 等于 `Function.prototype` 有这么几种说法：
80 |
81 | * 为了保持与其他函数保持一致
82 | * 为了说明一种关系，比如证明所有的函数都是 `Function` 的实例。
83 | * 函数都是可以调用 `call` `bind` 这些内置 API 的，这么写可以很好的保证函数实例能够使用这些 API。
84 |
85 | #### 注意点：
86 |
87 | 关于原型、原型链和构造函数有几点需要注意：
88 |
89 | * `__proto__` 是非标准属性，如果要访问一个对象的原型，建议使用 ES6 新增的 `Reflect.getPrototypeOf` 或者 `Object.getPrototypeOf()` 方法，而不是直接 obj.\_\_proto\_\_，因为非标准属性意味着未来可能直接会修改或者移除该属性。同理，当改变一个对象的原型时，最好也使用 `ES6` 提供的 `Reflect.setPrototypeOf` 或 `Object.setPrototypeOf`。
90 |
91 | ```javascript
92 | let target = {};
93 | let newProto = {};
94 | Reflect.getPrototypeOf(target) === newProto; // false
95 | Reflect.setPrototypeOf(target, newProto);
96 | Reflect.getPrototypeOf(target) === newProto; // true
97 | ```
98 |
99 | * 函数都会有 `prototype` ，除了 `Function.prototype.bind()` 之外。
100 | * 对象都会有 `__proto__` ，除了 `Object.prototype` 之外（其实它也是有的，之不过是 `null`）。
101 | * 所有函数都由 Function 创建而来，也就是说他们的 \_\_proto\_\_ 都等于 Function.prototype。
102 | * `Function.prototype` 等于 `Function.__proto__` 。
103 |
104 | ### 原型污染
105 |
106 | {% hint style="info" %}
107 | 原型污染是指：攻击者通过某种手段修改 JavaScript 对象的原型。
108 | {% endhint %}
109 |
110 | 什么意思呢，原理其实很简单。如果我们把 `Object.prototype.toString` 改成这样：
111 |
112 | ```javascript
113 | Object.prototype.toString = function () {alert('原型污染')};
114 | let obj = {};
115 | obj.toString();
116 | ```
117 |
118 | 那么当我们运行这段代码的时候浏览器就会弹出一个 `alert`，对象原生的 `toString` 方法被改写了，所有对象当调用 `toString` 时都会受到影响。
119 |
120 | 你可能会说，怎么可能有人傻到在源码里写这种代码，这不是搬起石头砸自己的脚么？没错，没人会在源码里这么写，但是攻击者可能会通过**表单**或者**修改请求内容**等方式使用原型污染发起攻击，来看下面一种情况：
121 |
122 | ```javascript
123 | 'use strict';
124 |
125 | const express = require('express');
126 | const bodyParser = require('body-parser')
127 | const cookieParser = require('cookie-parser');
128 | const path = require('path');
129 |
130 | const isObject = obj => obj && obj.constructor && obj.constructor === Object;
131 |
132 | function merge(a, b) {
133 | for (var attr in b) {
134 | if (isObject(a[attr]) && isObject(b[attr])) {
135 | merge(a[attr], b[attr]);
136 | } else {
137 | a[attr] = b[attr];
138 | }
139 | }
140 | return a
141 | }
142 |
143 | function clone(a) {
144 | return merge({}, a);
145 | }
146 |
147 | // Constants
148 | const PORT = 8080;
149 | const HOST = '0.0.0.0';
150 | const admin = {};
151 |
152 | // App
153 | const app = express();
154 | app.use(bodyParser.json())
155 | app.use(cookieParser());
156 |
157 | app.use('/', express.static(path.join(__dirname, 'views')));
158 | app.post('/signup', (req, res) => {
159 | var body = JSON.parse(JSON.stringify(req.body));
160 | var copybody = clone(body)
161 | if (copybody.name) {
162 | res.cookie('name', copybody.name).json({
163 | "done": "cookie set"
164 | });
165 | } else {
166 | res.json({
167 | "error": "cookie not set"
168 | })
169 | }
170 | });
171 | app.get('/getFlag', (req, res) => {
172 | var аdmin = JSON.parse(JSON.stringify(req.cookies))
173 | if (admin.аdmin == 1) {
174 | res.send("hackim19{}");
175 | } else {
176 | res.send("You are not authorized");
177 | }
178 | });
179 | app.listen(PORT, HOST);
180 | console.log(`Running on http://${HOST}:${PORT}`);
181 | ```
182 |
183 | 如果服务器中有上述的代码片段，攻击者只要将 `cookie` 设置成`{__proto__: {admin: 1}}` 就能完成系统的侵入。
184 |
185 | #### 原型污染的解决方案
186 |
187 | 在看原型污染的解决方案之前，我们可以看下 lodash 团队之前解决原型污染问题的手法：
188 |
189 | 
190 |
191 | 代码很简单，只要是碰到有 `constructor` 或者 `__proto__` 这样的敏感词汇，就直接退出执行了。这当然是一种防止原型污染的有效手段，当然我们还有其他手段：
192 |
193 | 1. 使用 `Object.create(null)`， 方法创建一个原型为 `null` 的新对象，这样无论对 原型做怎样的扩展都不会生效：
194 |
195 | ```javascript
196 | const obj = Object.create(null);
197 | obj.__proto__ = { hack: '污染原型的属性' };
198 | console.log(obj); // => {}
199 | console.log(obj.hack); // => undefined
200 | ```
201 |
202 | 2. 使用 `Object.freeze(obj)` 冻结指定对象，使之不能被修改属性，成为不可扩展对象：
203 |
204 | ```javascript
205 | Object.freeze(Object.prototype);
206 |
207 | Object.prototype.toString = 'evil';
208 |
209 | console.log(Object.prototype.toString);
210 | // => ƒ toString() { [native code] }
211 | ```
212 |
213 | 3. 建立 `JSON schema` ，在解析用户输入内容时，通过 `JSON schema` 过滤敏感键名。
214 | 4. 规避不安全的递归性合并。这一点类似 `lodash` 修复手段，完善了合并操作的安全性，对敏感键名跳过处理。
215 |
216 | ### 继承
217 |
218 | 终于可以来说说继承了，先来看看继承的概念，看下百度上是怎么说的：
219 |
220 | {% hint style="info" %}
221 | **继承**是[面向对象](https://baike.baidu.com/item/%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1/2262089)软件技术当中的一个概念，与[多态](https://baike.baidu.com/item/%E5%A4%9A%E6%80%81/2282489)、[封装](https://baike.baidu.com/item/%E5%B0%81%E8%A3%85/2796965)共为[面向对象](https://baike.baidu.com/item/%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1/2262089)的三个基本特征。继承可以使得子类具有父类的[属性](https://baike.baidu.com/item/%E5%B1%9E%E6%80%A7/20192958)和[方法](https://baike.baidu.com/item/%E6%96%B9%E6%B3%95/3009352)或者重新定义、追加属性和方法等。
222 | {% endhint %}
223 |
224 | 这段对于程序员来说，这个解释还是比较好理解的。接着往下翻，我看到了一条重要的描述：
225 |
226 | {% hint style="info" %}
227 | 子类的创建可以增加新数据、新功能，可以继承父类全部的功能，但是不能选择性的继承父类的部分功能。**继承是类与类之间的关系，不是对象与对象之间的关系。**
228 | {% endhint %}
229 |
230 | 这就尴尬了，`JavaScript` 里哪里来的类，只有对象。那照这么说岂不是不能实现纯正的继承了？所以才会有开头那句话：**与其叫继承，委托的说法反而更准确些。**
231 |
232 | 但是 ****`JavaScript` 是非常灵活的， 灵活这一特点给它带来很多缺陷的同时，也缔造出很多惊艳的优点。没有原生提供类的继承不要紧，我们可以用更多元的方式来实现 `JavaScript` 中的继承，比如说利用 `Object.assign`：
233 |
234 | ```javascript
235 | let person = { name: null, age: null };
236 | let man = Object.assign({}, person, { name: 'John', age: 23 });
237 | console.log(man); // => { name: 'John', age: 23 }
238 | ```
239 |
240 | 利用 `call` 和 `apply`：
241 |
242 | ```javascript
243 | let person = {
244 | name: null,
245 | sayName: function () {
246 | console.log(this.name);
247 | },
248 | sayAge: function () {
249 | console.log(this.age);
250 | }
251 | };
252 | let man = { name: 'Man', age: 23 };
253 | person.sayName.call(man); // => Man
254 | person.sayAge.apply(man); // => 23
255 | ```
256 |
257 | 甚至我们还可以使用深拷贝对象的方式来完成类似继承的操作……`JS` 中实现继承的手法多种多样，但是看看上面的代码不难发现一些问题：
258 |
259 | * 封装性不强，过于凌乱，写起来十分不便。
260 | * 根本无法判断子对象是从何处继承而来。
261 |
262 | 有没有办法解决这些问题呢？我们可以使用 `JavaScript` 中继承最常用的方式：**原型继承**
263 |
264 | ### 原型链继承
265 |
266 | {% hint style="info" %}
267 | 原型链继承，就是让对象实例通过原型链的方式串联起来，当访问目标对象的某一属性时，能顺着原型链进行查找，从而达到类似继承的效果。
268 | {% endhint %}
269 |
270 | ```javascript
271 | // 父类
272 | function SuperType (colors = ['red', 'blue', 'green']) {
273 | this.colors = colors;
274 | }
275 |
276 | // 子类
277 | function SubType () {}
278 | // 继承父类
279 | SubType.prototype = new SuperType();
280 | // 以这种方式将 constructor 属性指回 SubType 会改变 constructor 为可遍历属性
281 | SubType.prototype.constructor = SubType;
282 |
283 | let superInstance1 = new SuperType(['yellow', 'pink']);
284 | let subInstance1 = new SubType();
285 | let subInstance2 = new SubType();
286 | superInstance1.colors; // => ['yellow', 'pink']
287 | subInstance1.colors; // => ['red', 'blue', 'green']
288 | subInstance2.colors; // => ['red', 'blue', 'green']
289 | subInstance1.colors.push('black');
290 | subInstance1.colors; // => ['red', 'blue', 'green', 'black']
291 | subInstance2.colors; // => ['red', 'blue', 'green', 'black']
292 | ```
293 |
294 | 上述代码使用了最基本的原型链继承使得子类能够继承父类的属性，**原型继承的关键步骤就在于：将子类原型和父类原型关联起来，使原型链能够衔接上，**这边是直接将子类原型指向了父类实例来完成关联。
295 |
296 | 上述是原型继承的一种最初始的状态，我们分析上面代码，会发现还是会有问题：
297 |
298 | 1. 在创建子类实例的时候，不能向超类型的构造函数中传递参数。
299 | 2. 这样创建的子类原型会包含父类的实例属性，造成引用类型属性同步修改的问题。
300 |
301 | ### 组合继承
302 |
303 | 组合继承使用 `call` 在子类构造函数中调用父类构造函数，解决了上述两个问题：
304 |
305 | ```javascript
306 | // 组合继承实现
307 |
308 | function Parent(value) {
309 | this.value = value;
310 | }
311 |
312 | Parent.prototype.getValue = function() {
313 | console.log(this.value);
314 | }
315 |
316 | function Child(value) {
317 | Parent.call(this, value)
318 | }
319 |
320 | Child.prototype = new Parent();
321 |
322 | const child = new Child(1)
323 | child.getValue();
324 | child instanceof Parent;
325 | ```
326 |
327 | 然而它还是存在问题：父类的构造函数被调用了两次（创建子类原型时调用了一次，创建子类实例时又调用了一次），导致子类原型上会存在父类实例属性，浪费内存。
328 |
329 | ### 寄生组合继承
330 |
331 | 针对组合继承存在的缺陷，又进化出了“寄生组合继承”：使用 `Object.create(Parent.prototype)` 创建一个新的原型对象赋予子类从而解决组合继承的缺陷：
332 |
333 | ```javascript
334 | // 寄生组合继承实现
335 |
336 | function Parent(value) {
337 | this.value = value;
338 | }
339 |
340 | Parent.prototype.getValue = function() {
341 | console.log(this.value);
342 | }
343 |
344 | function Child(value) {
345 | Parent.call(this, value)
346 | }
347 |
348 | Child.prototype = Object.create(Parent.prototype, {
349 | constructor: {
350 | value: Child,
351 | enumerable: false, // 不可枚举该属性
352 | writable: true, // 可改写该属性
353 | configurable: true // 可用 delete 删除该属性
354 | }
355 | })
356 |
357 | const child = new Child(1)
358 | child.getValue();
359 | child instanceof Parent;
360 | ```
361 |
362 | 寄生组合继承的模式是现在业内公认的比较可靠的 `JS` 继承模式，`ES6` 的 `class` 继承在 `babel` 转义后，底层也是使用的寄生组合继承的方式实现的，这个会在 `ES6 class` 模块里详细说明。
363 |
364 | ### 继承关系判断
365 |
366 | 当我们使用了原型链继承后，怎样判断对象实例和目标类型之间的关系呢？
367 |
368 | #### instanceof
369 |
370 | 我们可以使用 `instanceof` 来判断二者间是否有继承关系，`instanceof` 的字面意思就是：xx 是否为 xxx 的实例。如果是则返回 `true` 否则返回 `false`：
371 |
372 | ```javascript
373 | function Parent () {}
374 | function Child () {}
375 | Child.prototype = new Parent();
376 | let parent = new Parent();
377 | let child = new Child();
378 |
379 | parent instanceof Parent; // => true
380 | child instanceof Child; // => true
381 | child instanceof Parent; // => true
382 | child instanceof Object; // => true
383 | ```
384 |
385 | `instanceof` 本质上是通过原型链查找来判断继承关系的，因此只能用来判断引用类型，对基本类型无效，我们可以手动实现一个简易版 `instanceof`：
386 |
387 | ```javascript
388 | function _instanceof (obj, Constructor) {
389 | if (typeof obj !== 'object' || obj == null) return false;
390 | let construProto = Constructor.prototype;
391 | let objProto = obj.__proto__;
392 | while (objProto != null) {
393 | if (objProto === construProto) return true;
394 | objProto = objProto.__proto__;
395 | }
396 | return false;
397 | }
398 | ```
399 |
400 | #### Object.prototype.isPrototypeOf\(obj\)
401 |
402 | 还可以利用 `Object.prototype.isPrototypeOf` 来间接判断继承关系，该方法用于判断一个对象是否存在于另一个对象的原型链上：
403 |
404 | ```javascript
405 | function Foo() {}
406 | function Bar() {}
407 | function Baz() {}
408 |
409 | Bar.prototype = Object.create(Foo.prototype);
410 | Baz.prototype = Object.create(Bar.prototype);
411 |
412 | var baz = new Baz();
413 |
414 | console.log(Baz.prototype.isPrototypeOf(baz)); // true
415 | console.log(Bar.prototype.isPrototypeOf(baz)); // true
416 | console.log(Foo.prototype.isPrototypeOf(baz)); // true
417 | console.log(Object.prototype.isPrototypeOf(baz)); // true
418 | ```
419 |
420 | ### 相关参考
421 |
422 | * [JavaScript 深入之从原型到原型链](https://github.com/mqyqingfeng/Blog/issues/2)
423 | * [最新：Lodash 严重安全漏洞背后你不得不知道的 JavaScript 知识](https://juejin.im/post/5d271332f265da1b934e2d48#heading-5)
424 | * [前端面试之道](https://juejin.im/book/5bdc715fe51d454e755f75ef)
425 |
426 |
--------------------------------------------------------------------------------
/javascript-basics/scope-and-closure.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | 几乎所有语言的最基础模型之一就是在变量中存储值，并且在稍后取出或修改这些值。在变量中存储值和取出值的能力，给程序赋予了状态。这就引伸出两个问题：这些变量被存储在哪里？程序如何在需要的时候找到它们？回答这些问题需要一组明确定义的规则，它定义了如何存储变量，以及如何找到这些变量。我们称这组规则为：作用域。
4 | ---
5 |
6 | # 作用域和闭包
7 |
8 | ### LHS 和 RHS 查询
9 |
10 | {% hint style="info" %}
11 | 在说 `javascript` 中的作用域之前，我想应该先了解一下 `LHS` 和 `RHS` 查询，这对于作用域的理解有所帮助。
12 | {% endhint %}
13 |
14 | 虽然 `javascript` 被认为是一门解释型语言/动态语言，但是它其实是一种编译型的语言。一般来说，需要运行一段 `javascript` 代码，有两个必不可少的东西：**JS 引擎** 和 **编译器。**前者类似于总管的角色，负责整个程序运行时所需的各种资源的调度；后者只是前者的一部分，负责将 `javascript` 源码编译成机器能识别的机器指令，然后交给引擎运行。
15 |
16 | #### 编译
17 |
18 | 在 `javascript` 中，一段源码在被执行之前大概会经历以下三个步骤，这也被称之为 **编译**：
19 |
20 | 1. **分词 / 词法分析：**编译器会先将一连串字符打断成（对于语言来说）有意义的片段，称为 token（记号），例如 `var a = 2;`。这段程序很可能会被打断成如下 token：`var`，`a`，`=`，`2`，和 `;`。
21 | 2. **解析 / 语法分析：**编译器将一个 `token` 的流（数组）转换为一个“抽象语法树”（`AST —— Abstract Syntax Tree`），它表示了程序的语法结构。
22 | 3. **代码生成：**编译器将上一步中生成的抽象语法树转换为机器指令，等待引擎执行。
23 |
24 | #### 执行
25 |
26 | 编译器一顿操作猛如虎，生成了一堆机器指令，JS 引擎开心地拿到这堆指令，开始执行，这个时候我们要说的 `LHS` 和 `RHS` 就登场了。
27 |
28 | `LHS (Left-hand Side)` 和 `RHS (Right-hand Side)` ，是在代码执行阶段 JS 引擎操作变量的两种方式，二者区别就是对变量的查询目的是 **变量赋值** 还是 **查询** 。
29 |
30 | **`LHS`** 可以理解为变量在赋值操作符`(=)`的左侧，例如 `a = 1`，当前引擎对变量 `a` 查找的目的是**变量赋值**。这种情况下，引擎不关心变量 `a` 原始值是什么，只管将值 `1` 赋给 `a` 变量。
31 |
32 | **`RHS`** 可以理解为变量在赋值操作符`(=)`的右侧，例如：`console.log(a)`，其中引擎对变量`a`的查找目的就是 **查询**，它需要找到变量 `a` 对应的实际值是什么，然后才能将它打印出来。
33 |
34 | 来看下面这段代码：
35 |
36 | ```javascript
37 | var a = 2; // LHS 查询
38 | ```
39 |
40 | 这段代码运行时，引擎做了一个 `LHS` 查询，找到 `a` ，并把新值 `2` 赋给它。再看下面一段：
41 |
42 | ```javascript
43 | function foo(a) { // LHS 查询
44 | console.log( a ); // RHS 查询
45 | }
46 |
47 | foo( 2 ); // RHS 查询
48 | ```
49 |
50 | 为了执行它，JS 引擎既做了 `LHS` 查询又做了 `RHS` 查询，只不过这里的 `LHS` 比较难发现。
51 |
52 | 总之，引擎想对变量进行获取 / 赋值，就离不开 `LHS` 和 `RHS` ，然而这两个操作只是手段，到哪里去获取变量才是关键。`LHS` 和 `RHS` 获取变量的位置就是 **作用域**。
53 |
54 | ### 什么是作用域
55 |
56 | > 简单来说，**作用域** 指程序中定义变量的区域，它决定了当前执行代码对变量的访问权限。
57 |
58 | `javascript` 中大部分情况下，只有两种作用域类型：
59 |
60 | * **全局作用域：**全局作用域为程序的最外层作用域，一直存在。
61 | * **函数作用域：**函数作用域只有函数被定义时才会创建，包含在父级函数作用域 / 全局作用域内。
62 |
63 | {% hint style="info" %}
64 | 由于作用域的限制，每段独立的执行代码块只能访问自己作用域和外层作用域中的变量，无法访问到内层作用域的变量。
65 | {% endhint %}
66 |
67 | ```javascript
68 | /* 全局作用域开始 */
69 | var a = 1;
70 |
71 | function func () { /* func 函数作用域开始 */
72 | var a = 2;
73 | console.log(a);
74 | } /* func 函数作用域结束 */
75 |
76 | func(); // => 2
77 |
78 | console.log(a); // => 1
79 |
80 | /* 全局作用域结束 */
81 | ```
82 |
83 | ### 作用域链
84 |
85 | 上面代码示范中，可执行代码块是能够在自己的作用域中找到变量的，那么如果在自己的作用域中找不到目标变量，程序能否正常运行？来看下面的代码：
86 |
87 | ```javascript
88 | function foo(a) {
89 | var b = a * 2;
90 |
91 | function bar(c) {
92 | console.log( a, b, c );
93 | }
94 |
95 | bar(b * 3);
96 | }
97 |
98 | foo(2); // 2 4 12
99 | ```
100 |
101 | 结合前面的知识我们知道，在 `bar` 函数内部，会做三次 `RHS` 查询从而分别获取到 `a` `b` `c` 三个变量的值。`bar` 内部作用域中只能获取到变量 `c` 的值，`a` 和 `b` 都是从外部 `foo` 函数的作用域中获取到的。
102 |
103 | {% hint style="info" %}
104 | 当可执行代码内部访问变量时，会先查找本地作用域，如果找到目标变量即返回，否则会去父级作用域继续查找...一直找到全局作用域。我们把这种作用域的嵌套机制，称为 **作用域链**。
105 | {% endhint %}
106 |
107 | 
108 |
109 | 用图片表示，上述代码一共有三层作用域嵌套，分别是：
110 |
111 | 1. 全局作用域
112 | 2. `foo` 作用域
113 | 3. `bar` 作用域
114 |
115 | {% hint style="warning" %}
116 | 需要注意，函数参数也在函数作用域中。
117 | {% endhint %}
118 |
119 | ### 词法作用域
120 |
121 | 明白了作用域和作用域链的概念，我们来看词法作用域。
122 |
123 | **词法作用域（`Lexical Scopes`）**是 `javascript` 中使用的作用域类型，**词法作用域** 也可以被叫做 **静态作用域**，与之相对的还有 **动态作用域**。那么 `javascript` 使用的 **词法作用域** 和 **动态作用域** 的区别是什么呢？看下面这段代码：
124 |
125 | ```javascript
126 | var value = 1;
127 |
128 | function foo() {
129 | console.log(value);
130 | }
131 |
132 | function bar() {
133 | var value = 2;
134 | foo();
135 | }
136 |
137 | bar();
138 |
139 | // 结果是 ???
140 | ```
141 |
142 | 上面这段代码中，一共有三个作用域：
143 |
144 | * 全局作用域
145 | * `foo` 的函数作用域
146 | * `bar` 的函数作用域
147 |
148 | 一直到这边都好理解，可是 `foo` 里访问了本地作用域中没有的变量 `value` 。根据前面说的，引擎为了拿到这个变量就要去 `foo` 的上层作用域查询，那么 `foo` 的上层作用域是什么呢？是它 **调用时** 所在的 bar 作用域？还是它 **定义时** 所在的全局作用域？
149 |
150 | 这个关键的问题就是 `javascript` 中的作用域类型——**词法作用域。**
151 |
152 | {% hint style="info" %}
153 | **词法作用域**，就意味着函数 **被定义的时候**，它的作用域就已经确定了，和拿到哪里执行没有关系，因此词法作用域也被称为 “**静态作用域**”。
154 | {% endhint %}
155 |
156 | 如果是动态作用域类型，那么上面的代码运行结果应该是 `bar` 作用域中的 `2` 。也许你会好奇什么语言是动态作用域？`bash` 就是动态作用域，感兴趣的小伙伴可以了解一下。
157 |
158 | ### 块级作用域
159 |
160 | 什么是块级作用域呢？简单来说，花括号内 `{...}` 的区域就是块级作用域区域。
161 |
162 | 很多语言本身都是支持块级作用域的。上面我们说，`javascript` 中大部分情况下，只有两种作用域类型：**全局作用域** 和 **函数作用域**，那么 `javascript` 中有没有块级作用域呢？来看下面的代码：
163 |
164 | ```javascript
165 | if (true) {
166 | var a = 1;
167 | }
168 |
169 | console.log(a); // 结果???
170 | ```
171 |
172 | 运行后会发现，结果还是 `1`，花括号内定义并赋值的 a 变量跑到全局了。这足以说明，`javascript` 不是原生支持块级作用域的，起码创作者创造这门语言的时候压根就没把块级作用域的事情考虑进去...（出来背锅！！）
173 |
174 | 但是 `ES6` 标准提出了使用 `let` 和 `const` 代替 `var` 关键字，来“创建块级作用域”。也就是说，上述代码改成如下方式，块级作用域是有效的：
175 |
176 | ```javascript
177 | if (true) {
178 | let a = 1;
179 | }
180 |
181 | console.log(a); // ReferenceError
182 | ```
183 |
184 | {% hint style="info" %}
185 | 关于 `let` 和 `const` 的更多细节，进入 [传送门](https://mitianyi.gitbook.io/frontend-interview-guide/es6/let-and-const)
186 | {% endhint %}
187 |
188 | ### 创建作用域
189 |
190 | 在 `javascript` 中，我们有几种创建 / 改变作用域的手段：
191 |
192 | 1. 定义函数，创建函数作用（推荐）：
193 |
194 | ```javascript
195 | function foo () {
196 | // 创建了一个 foo 的函数作用域
197 | }
198 | ```
199 |
200 | 2. 使用 `let` 和 `const` 创建块级作用域（推荐）：
201 |
202 | ```javascript
203 | for (let i = 0; i < 5; i++) {
204 | console.log(i);
205 | }
206 |
207 | console.log(i); // ReferenceError
208 | ```
209 |
210 | 3. `try catch` 创建作用域（不推荐）,`err` 仅存在于 `catch` 子句中：
211 |
212 | ```javascript
213 | try {
214 | undefined(); // 强制产生异常
215 | }
216 | catch (err) {
217 | console.log( err ); // TypeError: undefined is not a function
218 | }
219 |
220 | console.log( err ); // ReferenceError: `err` not found
221 | ```
222 |
223 | 4. 使用 eval “欺骗” 词法作用域（不推荐）：
224 |
225 | ```javascript
226 | function foo(str, a) {
227 | eval( str );
228 | console.log( a, b );
229 | }
230 |
231 | var b = 2;
232 |
233 | foo( "var b = 3;", 1 ); // 1 3
234 | ```
235 |
236 | 5. 使用 `with` 欺骗词法作用域（不推荐）：
237 |
238 | ```javascript
239 | function foo(obj) {
240 | with (obj) {
241 | a = 2;
242 | }
243 | }
244 |
245 | var o1 = {
246 | a: 3
247 | };
248 |
249 | var o2 = {
250 | b: 3
251 | };
252 |
253 | foo( o1 );
254 | console.log( o1.a ); // 2
255 |
256 | foo( o2 );
257 | console.log( o2.a ); // undefined
258 | console.log( a ); // 2 -- 全局作用域被泄漏了！
259 | ```
260 |
261 | {% hint style="success" %}
262 | 总结下来，能够使用的创建作用域的方式就两种：**定义函数创建** 和 **`let const` 创建**。
263 | {% endhint %}
264 |
265 | ### 作用域的应用场景
266 |
267 | 作用域的一个常见运用场景之一，就是 **模块化**。
268 |
269 | {% hint style="info" %}
270 | 由于 `javascript` 并未原生支持模块化导致了很多令人口吐芬芳的问题，比如 **全局作用域污染** 和 **变量名冲突**，代码结构臃肿且复用性不高。在正式的模块化方案出台之前，开发者为了解决这类问题，想到了 **使用函数作用域来创建模块** 的方案。
271 | {% endhint %}
272 |
273 | ```javascript
274 | function module1 () {
275 | var a = 1;
276 | console.log(a);
277 | }
278 |
279 | function module2 () {
280 | var a = 2;
281 | console.log(a);
282 | }
283 |
284 | module1(); // => 1
285 | module2(); // => 2
286 | ```
287 |
288 | 上面的代码中，构建了 `module1` 和 `module2` 两个代表模块的函数，两个函数内分别定义了一个同名变量 `a` ，由于函数作用域的隔离性质，这两个变量被保存在不同的作用域中（不嵌套），JS 引擎在执行这两个函数时会去不同的作用域中读取，并且外部作用域无法访问到函数内部的 `a` 变量。这样一来就巧妙地解决了 **全局作用域污染** 和 **变量名冲突** 的问题；并且，由于函数的包裹写法，这种方式看起来封装性好多了。
289 |
290 | 然而上面的函数声明式写法，看起来还是有些冗余，更重要的是，`module1` 和 `module2` 的函数名本身就已经对全局作用域造成了污染。我们来继续改写：
291 |
292 | ```javascript
293 | // module1.js
294 | (function () {
295 | var a = 1;
296 | console.log(a);
297 | })();
298 |
299 | // module2.js
300 | (function () {
301 | var a = 2;
302 | console.log(a);
303 | })();
304 | ```
305 |
306 | 将函数声明改写成 **立即调用函数表达式（`Immediately Invoked Function Expression` 简写 `IIFE`**），封装性更好，代码也更简洁，解决了模块名污染全局作用域的问题。
307 |
308 | {% hint style="warning" %}
309 | 函数声明和函数表达式，最简单的区分方法，就是看是不是 `function` 关键字开头：是 `function` 开头的就是函数声明，否则就是函数表达式。
310 | {% endhint %}
311 |
312 | 上面的代码采用了 `IIFE` 的写法，已经进化很多了，我们可以再把它强化一下，强化成后浪版，赋予它判断外部环境的权利——**选择的权力**。
313 |
314 | ```javascript
315 | (function (global) {
316 | if (global...) {
317 | // is browser
318 | } else if (global...) {
319 | // is nodejs
320 | }
321 | })(window);
322 | ```
323 |
324 | 让后浪继续奔涌，我们的想象力不足以想象 `UMD` 模块化的代码：
325 |
326 | ```javascript
327 | // UMD 模块化
328 | (function (root, factory) {
329 | if (typeof define === 'function' && define.amd) {
330 | // AMD
331 | define(['jquery'], factory);
332 | } else if (typeof exports === 'object') {
333 | // Node, CommonJS-like
334 | module.exports = factory(require('jquery'));
335 | } else {
336 | // Browser globals (root is window)
337 | root.returnExports = factory(root.jQuery);
338 | }
339 | }(this, function ($) {
340 | // methods
341 | function myFunc(){};
342 |
343 | // exposed public method
344 | return myFunc;
345 | }));
346 | ```
347 |
348 | 我看着作用域的模块化应用场景，真的是满怀羡慕。如果你也和我一样羡慕并且，想了解更多关于模块化的东西，请进入 [传送门](https://mitianyi.gitbook.io/frontend-interview-guide/javascript-basics/modularization)。
349 |
350 | ### 闭包
351 |
352 | 说完了作用域，我们来说说 **闭包**。
353 |
354 | > 能够访问其他函数内部变量的函数，被称为 **闭包**。
355 |
356 | 上面这个定义比较难理解，简单来说，**闭包就是函数内部定义的函数，被返回了出去并在外部调用**。我们可以用代码来表述一下：
357 |
358 | ```javascript
359 | function foo() {
360 | var a = 2;
361 |
362 | function bar() {
363 | console.log( a );
364 | }
365 |
366 | return bar;
367 | }
368 |
369 | var baz = foo();
370 |
371 | baz(); // 这就形成了一个闭包
372 | ```
373 |
374 | 我们可以简单剖析一下上面代码的运行流程：
375 |
376 | 1. 编译阶段，变量和函数被声明，作用域即被确定。
377 | 2. 运行函数 `foo()`，此时会创建一个 `foo` 函数的执行上下文，执行上下文内部存储了 `foo` 中声明的所有变量函数信息。
378 | 3. 函数 `foo` 运行完毕，将内部函数 `bar` 的引用赋值给外部的变量 `baz` ，此时 `baz` 指针指向的还是 `bar` ，因此哪怕它位于 `foo` 作用域之外，它还是能够获取到 `foo` 的内部变量。
379 | 4. `baz` 在外部被执行，`baz` 的内部可执行代码 `console.log` 向作用域请求获取 `a` 变量，本地作用域没有找到，继续请求父级作用域，找到了 `foo` 中的 `a` 变量，返回给 `console.log`，打印出 `2`。
380 |
381 | 闭包的执行看起来像是开发者使用的一个小小的 “作弊手段” ——**绕过了作用域的监管机制，从外部也能获取到内部作用域的信息**。闭包的这一特性极大地丰富了开发人员的编码方式，也提供了很多有效的运用场景。
382 |
383 | ### 闭包的应用场景
384 |
385 | {% hint style="info" %}
386 | 闭包的应用，大多数是在需要维护内部变量的场景下。
387 | {% endhint %}
388 |
389 | #### 单例模式
390 |
391 | 单例模式是一种常见的涉及模式，它保证了一个类只有一个实例。实现方法一般是先判断实例是否存在，如果存在就直接返回，否则就创建了再返回。单例模式的好处就是避免了重复实例化带来的内存开销：
392 |
393 | ```javascript
394 | // 单例模式
395 | function Singleton(){
396 | this.data = 'singleton';
397 | }
398 |
399 | Singleton.getInstance = (function () {
400 | var instance;
401 |
402 | return function(){
403 | if (instance) {
404 | return instance;
405 | } else {
406 | instance = new Singleton();
407 | return instance;
408 | }
409 | }
410 | })();
411 |
412 | var sa = Singleton.getInstance();
413 | var sb = Singleton.getInstance();
414 | console.log(sa === sb); // true
415 | console.log(sa.data); // 'singleton'
416 | ```
417 |
418 | #### 模拟私有属性
419 |
420 | `javascript` 没有 `java` 中那种 `public` `private` 的访问权限控制，对象中的所用方法和属性均可以访问，这就造成了安全隐患，内部的属性任何开发者都可以随意修改。虽然语言层面不支持私有属性的创建，但是我们可以用闭包的手段来模拟出私有属性：
421 |
422 | ```javascript
423 | // 模拟私有属性
424 | function getGeneratorFunc () {
425 | var _name = 'John';
426 | var _age = 22;
427 |
428 | return function () {
429 | return {
430 | getName: function () {return _name;},
431 | getAge: function() {return _age;}
432 | };
433 | };
434 | }
435 |
436 | var obj = getGeneratorFunc()();
437 | obj.getName(); // John
438 | obj.getAge(); // 22
439 | obj._age; // undefined
440 | ```
441 |
442 | #### 柯里化
443 |
444 | > 柯里化（`currying`），是把接受多个参数的函数变换成接受一个单一参数（最初函数的第一个参数）的函数，并且返回接受余下的参数而且返回结果的新函数的技术。
445 |
446 | 这个概念有点抽象，实际上柯里化是高阶函数的一个用法，`javascript` 中常见的 `bind` 方法就可以用柯里化的方法来实现：
447 |
448 | ```javascript
449 | Function.prototype.myBind = function (context = window) {
450 | if (typeof this !== 'function') throw new Error('Error');
451 | let selfFunc = this;
452 | let args = [...arguments].slice(1);
453 |
454 | return function F () {
455 | // 因为返回了一个函数，可以 new F()，所以需要判断
456 | if (this instanceof F) {
457 | return new selfFunc(...args, arguments);
458 | } else {
459 | // bind 可以实现类似这样的代码 f.bind(obj, 1)(2)，所以需要将两边的参数拼接起来
460 | return selfFunc.apply(context, args.concat(arguments));
461 | }
462 | }
463 | }
464 | ```
465 |
466 | 柯里化的优势之一就是 **参数的复用**，它可以在传入参数的基础上生成另一个全新的函数，来看下面这个类型判断函数：
467 |
468 | ```javascript
469 | function typeOf (value) {
470 | return function (obj) {
471 | const toString = Object.prototype.toString;
472 | const map = {
473 | '[object Boolean]' : 'boolean',
474 | '[object Number]' : 'number',
475 | '[object String]' : 'string',
476 | '[object Function]' : 'function',
477 | '[object Array]' : 'array',
478 | '[object Date]' : 'date',
479 | '[object RegExp]' : 'regExp',
480 | '[object Undefined]' : 'undefined',
481 | '[object Null]' : 'null',
482 | '[object Object]' : 'object'
483 | };
484 | return map[toString.call(obj)] === value;
485 | }
486 | }
487 |
488 | var isNumber = typeOf('number');
489 | var isFunction = typeOf('function');
490 | var isRegExp = typeOf('regExp');
491 |
492 | isNumber(0); // => true
493 | isFunction(function () {}); // true
494 | isRegExp({}); // => false
495 | ```
496 |
497 | 通过向 `typeOf` 里传入不同的类型字符串参数，就可以生成对应的类型判断函数，作为语法糖在业务代码里重复使用。
498 |
499 | ### 闭包的问题
500 |
501 | 从上面的介绍中我们可以得知，闭包的使用场景非常广泛，那我们是不是可以大量使用闭包呢？不可以，因为闭包过度使用会导致性能问题，还是看之前演示的一段代码：
502 |
503 | ```javascript
504 | function foo() {
505 | var a = 2;
506 |
507 | function bar() {
508 | console.log( a );
509 | }
510 |
511 | return bar;
512 | }
513 |
514 | var baz = foo();
515 |
516 | baz(); // 这就形成了一个闭包
517 | ```
518 |
519 | 乍一看，好像没什么问题，然而，它却有可能导致 **内存泄露**。
520 |
521 | 我们知道，`javascript` 内部的垃圾回收机制用的是引用计数收集：即当内存中的一个变量被引用一次，计数就加一。垃圾回收机制会以固定的时间轮询这些变量，将计数为 `0` 的变量标记为失效变量并将之清除从而释放内存。
522 |
523 | 上述代码中，理论上来说， `foo` 函数作用域隔绝了外部环境，所有变量引用都在函数内部完成，`foo` 运行完成以后，内部的变量就应该被销毁，内存被回收。然而闭包导致了全局作用域始终存在一个 `baz` 的变量在引用着 `foo` 内部的 `bar` 函数，这就意味着 `foo` 内部定义的 `bar` 函数引用数始终为 `1`，垃圾运行机制就无法把它销毁。更糟糕的是，`bar` 有可能还要使用到父作用域 `foo` 中的变量信息，那它们自然也不能被销毁... JS 引擎无法判断你什么时候还会调用闭包函数，只能一直让这些数据占用着内存。
524 |
525 | {% hint style="danger" %}
526 | 这种由于闭包使用过度而导致的内存占用无法释放的情况，我们称之为：**内存泄露**。
527 | {% endhint %}
528 |
529 | ### 内存泄露
530 |
531 | {% hint style="danger" %}
532 | **内存泄露** 是指当一块内存不再被应用程序使用的时候，由于某种原因，这块内存没有返还给操作系统或者内存池的现象。内存泄漏可能会导致应用程序卡顿或者崩溃。
533 | {% endhint %}
534 |
535 | 造成内存泄露的原因有很多，除了闭包以外，还有 **全局变量的无意创建**。开发者的本意是想将变量作为局部变量使用，然而忘记写 `var` 导致变量被泄露到全局中：
536 |
537 | ```javascript
538 | function foo() {
539 | b = 2;
540 | console.log(b);
541 | }
542 |
543 | foo(); // 2
544 |
545 | console.log(b); // 2
546 | ```
547 |
548 | 还有 `DOM` 的事件绑定，移除 `DOM` 元素前如果忘记了注销掉其中绑定的事件方法，也会造成内存泄露：
549 |
550 | ```javascript
551 | const wrapDOM = document.getElementById('wrap');
552 | wrapDOM.onclick = function (e) {console.log(e);};
553 |
554 | // some codes ...
555 |
556 | // remove wrapDOM
557 | wrapDOM.parentNode.removeChild(wrapDOM);
558 | ```
559 |
560 | ### 内存泄露的排查手段
561 |
562 | 可能大家都听过臭名昭著的 “内存泄露”，然而面对茫茫祖传代码，如何找到造成内存泄露的地方，却让人无从下手。这边我们还是借助谷歌的开发者工具， `Chrome` 浏览器，`F12` 打开开发者工具，我找了阮一峰老师的 ES6 网站演示。
563 |
564 | #### Performance
565 |
566 | 
567 |
568 | 
569 |
570 | 点击这个按钮启动记录，然后切换到网页进行操作，录制完成后点击 `stop` 按钮，开发者工具会从录制时刻开始记录当前应用的各项数据情况。
571 |
572 | 
573 |
574 | 选中`JS Heap`，下面展现出来的一条蓝线，就是代表了这段记录过程中，JS 堆内存信息的变化情况。
575 |
576 | 有大佬说，根据这条蓝线就可以判断是否存在内存泄漏的情况：**如果这条蓝线一直成上升趋势，那基本就是内存泄漏了。**其实我觉得这么讲有失偏颇，JS 堆内存占用率上升并不一定就是内存泄漏，只能说明有很多未被释放的内存而已，至于这些内存是否真的在使用，还是说确实是内存泄漏，还需要进一步排查。
577 |
578 | 
579 |
580 | #### memory
581 |
582 | 借助开发者工具的 Memory 选项，可以更精确地定位内存使用情况。
583 |
584 | 
585 |
586 | 
587 |
588 | 
589 |
590 | 当生成了第一个快照的时候，开发者工具窗口已经显示了很详细的内存占用情况。
591 |
592 | 字段解释：
593 |
594 | * `Constructor` — 占用内存的资源类型
595 | * `Distance` — 当前对象到根的引用层级距离
596 | * `Shallow Size` — 对象所占内存（不包含内部引用的其它对象所占的内存）\(单位：字节\)
597 | * `Retained Size` — 对象所占总内存（包含内部引用的其它对象所占的内存）\(单位：字节\)
598 |
599 | 将每项展开可以查看更详细的数据信息。
600 |
601 | 我们再次切回网页，继续操作几次，然后再次生成一个快照。
602 |
603 | 
604 |
605 | 
606 |
607 | 
608 |
609 | 这边需要特别注意这个 `#Delta` ，如果是正值，就代表新生成的内存多，释放的内存少。其中的闭包项，如果是正值，就说明存在内存泄漏。
610 |
611 | 
612 |
613 | 下面我们到代码里找一个内存泄漏的问题：
614 |
615 | 
616 |
617 | 
618 |
619 | ### 内存泄露的解决方案
620 |
621 | 1. 使用严格模式，避免不经意间的全局变量泄露：
622 |
623 | ```javascript
624 | "use strict";
625 |
626 | function foo () {
627 | b = 2;
628 | }
629 |
630 | foo(); // ReferenceError: b is not defined
631 | ```
632 |
633 | 2. 关注 `DOM` 生命周期，在销毁阶段记得解绑相关事件：
634 |
635 | ```javascript
636 | const wrapDOM = document.getElementById('wrap');
637 | wrapDOM.onclick = function (e) {console.log(e);};
638 |
639 | // some codes ...
640 |
641 | // remove wrapDOM
642 | wrapDOM.onclick = null;
643 | wrapDOM.parentNode.removeChild(wrapDOM);
644 | ```
645 |
646 | 或者可以使用事件委托的手段统一处理事件，减少由于事件绑定带来的额外内存开销：
647 |
648 | ```javascript
649 | document.body.onclick = function (e) {
650 | if (isWrapDOM) {
651 | // ...
652 | } else {
653 | // ...
654 | }
655 | }
656 | ```
657 |
658 | 3. 避免过度使用闭包。
659 |
660 | {% hint style="warning" %}
661 | 大部分的内存泄漏还是由于代码不规范导致的。**代码千万条，规范第一条，代码不规范，开发两行泪。**
662 | {% endhint %}
663 |
664 | ### 总结
665 |
666 | 1. `javascript` 语言层面只原生支持两种作用域类型：**全局作用域** 和 **函数作用域** 。全局作用域程序运行就有，函数作用域只有定义函数的时候才有，它们之间是包含的关系。
667 | 2. 作用域之间是可以嵌套的，我们把这种嵌套关系称为 **作用域链**。
668 | 3. 可执行代码在作用域中查询变量时，只能查询 **本地作用域** 及 **上层作用域**，不能查找内部的函数作用域。JS 引擎搜索变量时，会先询问本地作用域，找到即返回，找不到再去询问上层作用域...层层往上，直到全局作用域。
669 | 4. `javascript` 中使用的是 **“词法作用域”**，因此函数作用域的范围在函数定义时就已经被确定，和函数在哪执行没有关系。
670 | 5. 有权访问另一个函数内部变量的函数，我们称为 **闭包**。**闭包的本质是利用了作用域的机制，来达到外部作用域访问内部作用域的目的。**
671 | 6. 闭包的使用场景非常广泛，然而过度使用会导致闭包内的变量所占用的内存空间无法释放，带来 **内存泄露** 的问题。
672 | 7. 我们可以借助于 `chrome` 开发者工具查找代码中导致了内存泄露的代码。
673 | 8. 避免内存泄露的几种方法：避免使用全局变量、谨慎地为`DOM` 绑定事件、避免过度使用闭包。最重要的，还是代码规范。 😃
674 |
675 | ### 相关参考
676 |
677 | * 《你不知道的JavaScript》
678 | * [“You Don’t Know JS:” My Understanding of Scopes and Closures](https://medium.com/better-programming/you-dont-know-js-my-understanding-of-scopes-closures-e0d2bfe4c328)
679 | * [Closures - JavaScript \| MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures)
680 | * [JavaScript深入之词法作用域和动态作用域](https://github.com/mqyqingfeng/Blog/issues/3)
681 | * [你不懂 JS —— 作用域与闭包](https://www.kancloud.cn/kancloud/you-dont-know-js-scope-closures/516609)
682 | * [从 LHS 与 RHS 角度浅谈Js变量声明与赋值](https://github.com/MrErHu/blog/issues/12)
683 | * [前端面试之道](https://juejin.im/book/5bdc715fe51d454e755f75ef)
684 | * [记录一次前端内存泄漏排查经历](https://juejin.im/post/5df33d97518825126e639c60)
685 |
686 |
--------------------------------------------------------------------------------
/performance-optimization/deounce-throttle.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: 这两个东西，你肯定听过，就是两种优化浏览器性能的手段。相关文章你肯定也看过，如果还是不太清楚，没关系，看完这篇短文，相信你能轻松理解其中差别。
3 | ---
4 |
5 | # 防抖和节流
6 |
7 | ### 防抖（deounce）
8 |
9 | 我们先说防抖吧，这里有个小笑话，看完你应该就秒懂了：
10 |
11 | > 小明军训，教官发令：向左转！向右转！向后转！大家都照着做，唯有小明坐下来休息，教官火的一批，大声斥问他为啥不听指挥？小明说，我准备等你想好到底往哪个方向转，我再转。
12 |
13 | 虽然是个笑话，却很好地说明了防抖的定义：**给一个固定时间，如果你开始触发动作，并且在这个固定时间内不再有任何动作，我就执行一次，否则我每次都会重新开始计时**。我们可以用极端情况理解它：如果给定时间间隔足够大，并且期间一直有动作触发，那么回调就永远不会执行。放在笑话的语境里就是，只有教官最后一次发号后，小明才会转。
14 |
15 | ### 节流（throttle）
16 |
17 | 如果你理解了防抖，关于节流，就更好理解了
18 |
19 | > 学生上自习课，班主任五分钟过来巡视一次，五分钟内随便你怎么皮，房顶掀了都没事，只要你别在五分钟的时间间隔点上被班主任逮到，逮不到就当没发生，逮到她就要弄你了。
20 |
21 | 在这里，班主任就是节流器；你搞事，就是用户触发的事件；你被班主任逮住弄，就是执行回调函数。
22 |
23 | 节流的定义：**用户会反复触发一些操作，比如鼠标移动事件，此时只需要指定一个“巡视”的间隔时间，不管用户期间触发多少次，只会在间隔点上执行给定的回调函数。**，我们同样可以用极端情况来理解：如果给定的间隔时间是 `240毫秒`，用户永不间断地在屏幕上疯狂移动鼠标，那么你的回调函数会分别在 `240毫秒`、 `480毫秒`、 `720毫秒`... 就这么一直执行下去
24 |
25 | ### 这俩有啥用？
26 |
27 | * 防抖（deounce）:
28 | * 可用于**input.change**实时输入校验，比如输入实时查询，你不可能摁一个字就去后端查一次，肯定是输一串，统一去查询一次数据。
29 | * 可用于 **window.resize** 事件，比如窗口缩放完成后，才会重新计算部分 `DOM` 尺寸
30 | * 节流（throttle），用于监听 `mousemove`、 鼠标滚动等事件，通常可用于：**拖拽动画**、**下拉加载**。
31 |
32 | {% hint style="info" %}
33 | 节流通常用在比防抖刷新更频繁的场景下，而且大部分是需要涉及动画的操作。
34 | {% endhint %}
35 |
36 | ### Talking is cheap show me the code
37 |
38 | #### 防抖
39 |
40 | ```javascript
41 | function debounce (fn, delay = 200) {
42 | let timeout;
43 | return function() {
44 | // 重新计时
45 | timeout && clearTimeout(timeout);
46 | timeout = setTimeout(fn.bind(this), delay, ...arguments);
47 | }
48 | }
49 |
50 | const handlerChange = debounce(function () {alert('更新触发了')})
51 |
52 | // 绑定监听
53 | document.querySelector("input").addEventListener('input', handlerChange);
54 | ```
55 |
56 | #### 节流
57 |
58 | ```javascript
59 | function throttle (fn, threshhold = 200) {
60 | let timeout;
61 | // 计算开始时间
62 | let start = new Date();
63 | return function () {
64 | // 触发时间
65 | const current = new Date() - 0;
66 | timeout && clearTimeout(timeout);
67 | // 如果到了时间间隔点，就执行一次回调
68 | if (current - start >= threshhold) {
69 | fn.call(this, ...arguments);
70 | // 更新开始时间
71 | start = current;
72 | } else {
73 | // 保证方法在脱离事件以后还会执行一次
74 | timeout = setTimeout(fn.bind(this), threshhold, ...arguments);
75 | }
76 | }
77 | }
78 |
79 | let handleMouseMove = throttle(function(e) {
80 | console.log(e.pageX, e.pageY);
81 | })
82 |
83 | // 绑定监听
84 | document.querySelector("#panel").addEventListener('mousemove', handleMouseMove);
85 | ```
86 |
87 | {% hint style="info" %}
88 | 从代码上看不难发现，节流只是在防抖的基础上加了时间差的判断，多穿了件马甲而已。
89 | {% endhint %}
90 |
91 | ### 小兄弟，你是否还有很多问号？？
92 |
93 | 1. 防抖用在 `input.change` 上我能理解，鼠标拖拽功能为啥不能用防抖？用的话会发生什么？
94 |
95 | > 仔细想一想，简单来说，防抖其实是只会触发一次，明显不能用在这种拖拽场景下，如果硬用上去，会出现用户拖了弹框它不动，过了一会儿“啪”地就跳过去了。出现这种情况，老板是要请你喝茶的。
96 |
97 | 2. 节流的代码，为什么要加上那句 `setTimeout` ？我不加会怎么样？
98 |
99 | > 这句代码的主要作用，说白了其实就是“兜底”，它确保了你的回调不管怎么样，一定会执行一次。还是用鼠标拖拽弹框功能举例，这个兜底解决了拖拽弹框在速度很快的情况下弹框不动的问题、也确保你最后拖拽完成，放开鼠标，弹框能回到你鼠标的位置，就是代码注释里写的：保证方法在脱离事件以后还会执行一次。
100 |
101 | 其实这两个问题，是我初见防抖和节流的时候所疑惑的，希望也能帮助到你。
102 |
103 | ### 再深入一点
104 |
105 | 本来是没有写这块内容的，但是评论区有朋友指出了节流函数存在的问题，我就顺带着又了解了一些防抖和节流的细节。
106 |
107 | 我们可以从上面的节流函数入手，你能否看出存在什么问题呢？这个也是评论区朋友指出的：**这个节流函数第一次不会立即执行，而是会等待一段时间执行，并且这个等待时间越长，延迟越是明显**，我们用这个思路再审视一下防抖函数，也同样有这个问题。
108 |
109 | 那么怎么解决呢？针对防抖和节流，其实有**立即执行**和**非立即执行**两种版本，上面写的就是非立即执行版本。想解决上面的问题也很简单，把函数改造一下，使用立即执行版本就可以了~只需要改变一行代码。（同理，节流也是类似）
110 |
111 | ```javascript
112 | // 立即执行的防抖函数
113 | function debounce (fn, delay = 200) {
114 | let timeout;
115 | return function() {
116 | // 如果 timeout == null 说明是第一次，直接执行回调，否则重新计时
117 | + timeout == null ? fn.call(this, ...arguments) : clearTimeout(timeout);
118 | timeout = setTimeout(fn.bind(this), delay, ...arguments);
119 | }
120 | }
121 |
122 | const handlerChange = debounce(function () {alert('更新触发了')})
123 |
124 | // 绑定监听
125 | document.querySelector("input").addEventListener('input', handlerChange);
126 | ```
127 |
128 | ### 可视化
129 |
130 | 如果你还是无法直观感受二者差别，进入 [传送门](http://demo.nimius.net/debounce_throttle/)
131 |
132 | ### 相关参考
133 |
134 | [知乎：函数防抖与函数节流](https://zhuanlan.zhihu.com/p/38313717) 文章是大佬司徒正美写的，谨以技术缅怀大佬。
135 |
136 | ### 总结
137 |
138 | 关于节流和防抖这两个概念，我也看过很多解说，说实话，很少有文章能真的说清楚的。基本上就是官腔+代码流的一套组合拳，都在说 `Talking is cheap show me the code`，但是很多时候，往往是 `Fucking code is so difficult, talk to me please.` 真正能让人豁然开朗的，应该是大白话。
139 |
140 | 真心希望这篇文章能帮到你，帮到了点个赞，感谢！
141 |
142 |
--------------------------------------------------------------------------------