只有理解了 JavaScrip 的执行上下文，你才能更好地理解 JavaScript 语言本身，比如变量提升、作用域和闭包等。不仅如此，理解执行上下文和调用栈的概念还能助你成为一名更合格的前端开发者。这次我们就从上下文的角度讲一下js的变量提升。
上周的博客中我们讨论并实现了图的拓扑排序，这周我们继续学习图的另外一种基础的算法，最短路径算法Dijkstra算法，以及如何将其改造成我们平时导航或者游戏中经常使用中用到的寻路算法。
今天看了一篇关于拓扑排序的思路和应用的文章，自己手动实现记录一下。
算法是构建在具体的数据结构之上的。针对这个问题，我们先来看下，如何将问题背景抽象成具体的数据结构？
我们可以把源文件与源文件之间的依赖关系，抽象成一个有向图。每个源文件对应图中的一个顶点，源文件之间的依赖关系就是顶点之间的边。
如果 a 先于 b 执行，也就是说 b 依赖于 a，那么就在顶点 a 和顶点 b 之间，构建一条从 a 指向 b 的边。而且，这个图不仅要是有向图，还要是一个有向无环图，也就是不能存在像 a->b->c->a 这样的循环依赖关系。因为图中一旦出现环，拓扑排序就无法工作了。实际上，拓扑排序本身就是基于有向无环图的一个算法。
这周POC了几个渗透测试工具，分别是Burp Suite，OWASP Zap。
其中Burp的很多功能都是收费的，免费版基本只是用来做请求拦截的。
所以最后选择Zap对一个Express项目进行了扫描了漏洞修复，这里简单记录一下Zap的使用教程，以及Express的一些安全实践。
上周在使用一个elementUI的table是，发现每次点击table的checkbox的时候，页面都会卡顿接近两秒钟，于是就用vue的devtools去记录了下每次的操作时间消耗在哪里，发现主要是因为elementUI的table虽然提供了树形数据和懒加载的功能，虽然子级节点没有展开，但是已经渲染出来了。
所以elementUI的table提供了懒加载的功能，但是这个懒加载的功能是有问题的，因为懒加载函数只会调用一次，以后无论如何变化数据，子节点都不会发生改变。
经过对vue和elementUI的源码分析，找到原因后适当fix了一下，在这里记录一下。
前面的六篇博客已经帮助我们基本搞清楚了，vue的响应式原理，数据驱动，组件化和组件更新等概念和原理，而其中关于组件化和组件更新的部分，我们是在已有render函数的基础上来讲的，也就是说我们已经有了vnode，再去讨论的vnode如何渲染更新的。
这篇博客我们就回过头来看看vue的compiler是如何将template变成render函数的。
了解编译的流程有什么好处呢？我个人觉得可以帮助我们对于一些vue自身的语法糖的原理有个更好的理解。
由于Compiler的细节非常多，所以大概有个结论和印象即可，其中很多关于vue自身的语法处理也不会细讲，只会用slot来做个例子。
数据结构与算法是一个非常大的范围，各种不同的问题需要不同的算法，这些算法或复杂或简单。这篇博客简单通过经典的背包问题介绍四种非常基本且常用的算法思想，分别是贪心，分治，回溯，动规。
这四种是算法思想，不是具体的算法，主要是理解其思路，而不是具体的实现。
这篇文章主要是帮我我把以前略显零散的知识点重新总结一下，所以很多具体内容在以前的其他博客中。
我们平时工作中会经常使用SringA.indexOf(StringB)这种子串查找函数，如果让我们自己实现，我们会怎么实现？
这次就记录下我们常说的四种字符串匹配算法，分别是BF，RK，BM和KMP算法。
前两种容易想到，也很简单，后面两种了解原理即可，这两种算是算法中比较难理解的两种，就算理解也很难写出没有bug的程序。
**对于计算机而言，它只知道利用内存地址去访问内存中的变量，我们人为分出了两种存储形式，一种是连续存储（也就是数组），一种是链式存储（链表），至于其他的数据结构其实都是对这两种存储形式的利用。任何一种数据结构都可以用两种存储形式去实现，只有合适不合适的问题，没有能不能的问题，因为最终都是利用内存地址去访问内存。**队列，栈我们平时都用数组实现，但是用链表也可以，比如树我们大部分情况下用链表实现，但是其实像完全二叉树用数组去实现也完全没问题。
这篇博客主要是**通过一些例子去分析这些情况下我们需要什么数据结构的什么特性，为了更好地满足这些特性，我们需要用数组还是链表去实现。**对于所有的内容都不会去细讲，更不会涉及具体实现，因为都很基础，但真要展开讲也会变成长篇大论，我们更主要的是从一个更高的层面看他们的一些特性。