JS防抖实例是否共享闭包变量timeoutRef的疑问

核心结论：debouncedFoo和debouncedBar完全不共享timeoutRef变量，这是你推导偏差的根本原因。

闭包与函数执行上下文的基本规则 #

每次调用JavaScript函数时，引擎都会为这次调用创建一个全新的、独立的执行上下文，函数内部声明的所有局部变量都只存在于这个上下文里，和其他次调用产生的同名变量没有任何关联。闭包捕获的是自己被创建时所在的那个执行上下文中的变量，不同次外层函数调用生成的闭包，绑定的是完全独立的变量副本。

对应到你的代码执行流程 #

1. 执行const debouncedFoo = debounce(foo, 10000)时
   debounce第一次运行，生成第一个独立执行上下文，在这个上下文里创建了第一个专属的timeoutRef变量，返回的debouncedFoo函数闭包绑定的就是这个专属变量。
2. 执行const debouncedBar = debounce(bar, 2000)时
   debounce第二次运行，生成第二个完全独立的执行上下文，在这个上下文里创建了第二个和前者毫无关系的timeoutRef变量，返回的debouncedBar函数闭包绑定的是这第二个专属变量。
3. 调用debouncedFoo()时
   操作的是第一个上下文里的timeoutRef，给它赋值foo对应的10秒定时器ID，不会影响第二个上下文里的变量。
4. 调用debouncedBar()时
   操作的是第二个上下文里的timeoutRef，第一次执行时这个变量是undefined，clearTimeout(undefined)不会产生任何效果，之后给它赋值bar对应的2秒定时器ID，根本碰不到foo设置的那个定时器。

你的防抖实现本身是正确的：只有多次调用同一个防抖后的函数时，才会共享同一个timeoutRef，实现重置计时的效果——比如连续调用10次debouncedFoo，后一次调用总会清除前一次设置的定时器，最终只会在最后一次调用的10秒后执行一次foo。

为什么你之前的预期不对 #

你假设两次debounce调用共用了同一个timeoutRef，这种情况只有把timeoutRef声明到debounce函数的外层作用域才会发生，这也是常见的错误防抖写法：

// 错误写法：所有防抖函数共享同一个timeoutRef，会互相干扰
let timeoutRef;
function debounce(fn, timeout) {
    return function (...args) {
        const context = this;
        function cb() {
            fn.apply(context, args);
        }
        clearTimeout(timeoutRef);
        timeoutRef = setTimeout(cb, timeout);
    };
}

如果用这个错误实现，你调用debouncedBar()时确实会清除foo的定时器，最终只输出bar is called，但这不符合防抖函数的设计预期。

实际运行结果的逻辑 #

两个定时器完全独立互不干扰：

• 调用后2秒，bar的定时器到期，输出bar is called
• 调用后10秒，foo的定时器到期，输出foo is called
  和你实际运行得到的结果完全一致。

内容的提问来源于stack exchange，提问作者Ayyappa Gollu