今天在翻阅lodash源码时候发现，作者的思路更缜密，通常上述做法，我们并不会关心性能，每次事件触发，都会主动销毁定时器，创建定时器，这无疑增加了性能消耗，接下来，我们来瞅一眼lodash的代码结构

function debounce (fn, wait, options) {      let lastCalltime, lastInvokeTime, timeId      //防抖函数      function $debounce () {}      //触发fn      function invokeFunc () {}      //定时器绑定     function leadingEdge () {}      //内部计算触发时间     function timerExpired () {}      //重新计算时间      function remainingWait (time) {}      //是否可以更新     function shouldInvoke (time) {}      //返回     return $debounce  }复制代码

代码结构如上述，首先我想说的是，作者的思路，而不是一上来，我们就扎进代码里，通过lodash的代码我想到了2点问题，如果有补充，大佬们下方留言

1.  计算执行剩余时间，在首次进入函数时，并且记录调用函数的时间lastCallTime，由于作用域链的机制，我们内部所有的函数都可以访问都这个lastCallTime变量，然后我们就会开启一个定时器，这个定时器，不会被取消，内部会到指定wait时间后执行，执行过程中，会判断当前执行时间和lastCallTime差值是否大于等于wait，来执行，这里普及一个知识点，void 0 和 undefined，我们知道undefined不是关键字，所以存在被修改的风险，但是void运算符可以把任意运算变为undefined，所以推荐大家使用void，好了我们看代码  

   function shouldInvoke (time) {    return (Date.now() - time >= wait) || lastInvokeTime === void 0;}复制代码

2. 避免重复取消和创建定时器，这块小白感觉是设计最好的，之前我们的对应关系是，高频操作进入函数内部就是定时器 + 需要执行的函数，现在lodash这这个基础上多加了一层，timerExpired函数，timerExpired会在内部自动判断要不要执行我们传入的回调函数，invokeFunc，在它的内部机制过程中，会不断的去调用上述函数shouldInvoke，如果不满足条件，会去重新计算调用时间函数remainingWait ，避免延迟执行，看代码              

   function timerExpired () {  setTimeout(timerExpired, remainingWait(Date.now()))}复制代码