节流。就是拧紧水龙头让水少流一点，但是不是不让水流了。想象一下在现实生活中有时候我们需要接一桶水，接水的同时不想一直站在那等着，可能要离开一会去干一点别的事请，让水差不多流满一桶水的时候再回来，这个时候，不能把水龙头开的太大，不然还没回来水就已经满了，浪费了好多水，这时候就需要节流，让自己回来的时候水差不多满了。那在JS里有没有这种情况呢，典型的场景是图片懒加载监听页面的scoll事件，或者监听鼠标的mousemove事件，这些事件对应的处理方法相当于水，由于scroll和mousemove在鼠标移动的时候会被浏览器频繁的触发，会导致对应的事件也会被频繁的触发（水流的太快了），这样就会造成很大的浏览器资源开销，而且好多中间的处理是不必要的，这样就会造成浏览器卡顿的现象，这时候就需要节流，如何节流呢？我们无法做到让浏览器不去触发对应的事件，但是可以做到让处理事件的方法执行频率减少，从而减少对应的处理开销。
去抖。最早接触这个词应该是在高中物理里面学到的，有时候开关在在真正闭合之前可能会发生一些抖动现象，如果抖动的明显的话，对应的小灯泡可能会闪烁，把灯泡闪坏了不重要，万一把眼睛再给闪坏了可就麻烦了，这个时候就有去抖电路的出现。而在我们的页面里，也有这种情况，假设我们的一个输入框，输入内容的同时可能会去后台查询对应的联想 词，如果用户输入的同时，频繁的触发input事件，然后频繁的向后抬发送请，那么直到用户输入完成时，之前的请求都应该是多余的，假设网络慢一点，后台返回的数据比较慢，那么显示的联想词可能会出现频繁的变换，直到最后的一个请求返回。这个时候就可以在一定时间内监听是否再次输入，如果没有再次输入则认为本次输入完成，发送请求，否则就是判定用户仍在输入，不发送请求。
去抖和节流是不同的，因为节流虽然中间的处理函数被限制了，但是只是减少了频率，而去抖则把中间的处理函数全部过滤掉了，只执行规判定时间内的最后一个事件。
去抖。最早接触这个词应该是在高中物理里面学到的，有时候开关在在真正闭合之前可能会发生一些抖动现象，如果抖动的明显的话，对应的小灯泡可能会闪烁，把灯泡闪坏了不重要，万一把眼睛再给闪坏了可就麻烦了，这个时候就有去抖电路的出现。而在我们的页面里，也有这种情况，假设我们的一个输入框，输入内容的同时可能会去后台查询对应的联想 词，如果用户输入的同时，频繁的触发input事件，然后频繁的向后抬发送请，那么直到用户输入完成时，之前的请求都应该是多余的，假设网络慢一点，后台返回的数据比较慢，那么显示的联想词可能会出现频繁的变换，直到最后的一个请求返回。这个时候就可以在一定时间内监听是否再次输入，如果没有再次输入则认为本次输入完成，发送请求，否则就是判定用户仍在输入，不发送请求。
去抖和节流是不同的，因为节流虽然中间的处理函数被限制了，但是只是减少了频率，而去抖则把中间的处理函数全部过滤掉了，只执行规判定时间内的最后一个事件。
网友回复
我知道答案，我要回答
