本篇内容从节流和去抖的概念基础知识讲起，对JS函数做了详细的分析，一起来看下：
1、什么是节流和去抖？
节流。就是拧紧水龙头让水少流一点，但是不是不让水流了。想象一下在现实生活中有时候我们需要接一桶水，接水的同时不想一直站在那等着，可能要离开一会去干一点别的事请，让水差不多流满一桶水的时候再回来，这个时候，不能把水龙头开的太大，不然还没回来水就已经满了，浪费了好多水，这时候就需要节流，让自己回来的时候水差不多满了。那在JS里有没有这种情况呢，典型的场景是图片懒加载监听页面的scoll事件，或者监听鼠标的mousemove事件，这些事件对应的处理方法相当于水，由于scroll和mousemove在鼠标移动的时候会被浏览器频繁的触发，会导致对应的事件也会被频繁的触发（水流的太快了），这样就会造成很大的浏览器资源开销，而且好多中间的处理是不必要的，这样就会造成浏览器卡顿的现象，这时候就需要节流，如何节流呢？我们无法做到让浏览器不去触发对应的事件，但是可以做到让处理事件的方法执行频率减少，从而减少对应的处理开销。
去抖。最早接触这个词应该是在高中物理里面学到的，有时候开关在在真正闭合之前可能会发生一些抖动现象，如果抖动的明显的话，对应的小灯泡可能会闪烁，把灯泡闪坏了不重要，万一把眼睛再给闪坏了可就麻烦了，这个时候就有去抖电路的出现。而在我们的页面里，也有这种情况，假设我们的一个输入框，输入内容的同时可能会去后台查询对应的联想 词，如果用户输入的同时，频繁的触发input事件，然后频繁的向后抬发送请，那么直到用户输入完成时，之前的请求都应该是多余的，假设网络慢一点，后台返回的数据比较慢，那么显示的联想词可能会出现频繁的变换，直到最后的一个请求返回。这个时候就可以在一定时间内监听是否再次输入，如果没有再次输入则认为本次输入完成，发送请求，否则就是判定用户仍在输入，不发送请求。
去抖和节流是不同的，因为节流虽然中间的处理函数被限制了，但是只是减少了频率，而去抖则把中间的处理函数全部过滤掉了，只执行规判定时间内的最后一个事件。
2、JS实现。
前面BB了这么多，感谢你耐心的看到这里，接下来我们来自己动手看看如何实现节流和去抖。
节流：
再看如何调用：
这时候f疯狂的滚动页面，会发现会400ms打印一个123，而没有节流的话会不断地打印， 你可以改变wait参数去感受下不同。
但是到这里，我们的节流方法是不完善的，因为我们的方法没有获取事件发生时的this对象，而且由于我们的方法简单粗暴的通过判断这次触发的时间和上次执行时间的间隔来决定是否执行回调，这样就会造成最后一次触发无法执行，或者用户出发的间隔确实很短，也无法执行，造成了误杀，所以需要对方法进行完善。
去抖：
去抖的方法，和节流思路一致，但是只有在抖动被判定结束后，方法才会得到执行。
这时候按照之前同样的方式调用，会发现无论怎么疯狂的滚动窗口，只有停止滚动时，才会执行对应的事件。
去抖和节流已经有很多成熟的js进行了实现，其大致思路基本是这样的。
方法一
1.这种实现方式的思路很好理解：设置一个一间隔时间，比如50毫秒，以此时间为基准设置定时器，当第一次触发事件到第二次触发事件间隔小于50毫秒时，清除这个定时器，并设置一个新的定时器，以此类推，直到有一次事件触发后50毫秒内没有重复触发。代码如下：
这种设计方式有一个问题：本来应该多次触发的事件，可能最终只会发生一次。具体来说，一个循序渐进的滚动事件，如果用户滚动太快速，或者程序设置的函数节流间隔时间太长，那么最终滚动事件会呈现为一个很突然的跳跃事件，中间过程都被节流截掉了。这个例子举的有点夸张了，不过使用这种方式进行节流最终是会明显感受到程序比不节流的时候“更突兀”，这对于用户体验是很差的。有一种弥补这种缺陷的设计思路。
方法二
2.第二种实现方式的思路与第一种稍有差别：设置一个间隔时间，比如50毫秒，以此时间为基准稳定分隔事件触发情况，也就是说100毫秒内连续触发多次事件，也只会按照50毫秒一次稳定分隔执行。代码如下：
相比于第一种方法，第二种方法也许会比第一种方法执行更多次（有时候意味着更多次请求后台，即更多的流量），但是却很好的解决了第一种方法清除中间过程的缺陷。因此在具体场景应根据情况择优决定使用哪种方法。
