第三方库添加的Window.scroll事件监听器节流改造无效问题排查

首先，你的思路方向是对的——第三方库绑定的scroll事件太耗性能，想用Underscore的节流来包装，但直接修改evt.handler的方式根本影响不到浏览器实际运行的事件回调，这就是为什么性能没提升、开发者工具里还能看到原始监听器的原因。

问题根源：jQuery的事件包装机制 #

当你用jQuery绑定事件时，它不会直接把你的handler绑定到浏览器的事件上。jQuery会把你的handler包裹在一个内部包装函数里，然后把这个包装函数注册给浏览器。你通过$._data(window, 'events').scroll拿到的evt.handler，只是jQuery存储的原始handler引用，但浏览器实际触发的是那个包装函数——它内部保存的是最初的handler引用，你后续修改evt.handler不会更新这个已经存在的引用关系。

简单说：浏览器记住的是jQuery的包装函数，这个函数还是会调用原来的未节流的handler，你改jQuery内部的存储项没用。

正确的解决方法：先解绑，再重新绑定节流后的handler #

既然直接修改内部存储不生效，那我们换个思路：把所有原有的scroll事件先解绑，然后把每个handler用_.throttle包装后重新绑定到window上。

代码示例：

jQuery(document).ready(function($) {
  // 先获取所有已绑定的scroll事件处理函数
  const scrollEvents = $._data(window, 'events')?.scroll;
  if (!scrollEvents) return; // 如果没有scroll事件就直接退出
  
  // 提取所有原始handler
  const originalHandlers = scrollEvents.map(evt => evt.handler);
  
  // 移除window上所有的scroll事件
  $(window).off('scroll');
  
  // 逐个将handler节流后重新绑定
  originalHandlers.forEach(handler => {
    $(window).on('scroll', _.throttle(handler, 200));
  });
});

关键注意点 #

1. 执行时机：一定要确保这段代码在第三方库完成scroll事件绑定之后运行。如果document.ready还太早，可以换成window.addEventListener('load', ...)，或者在开发者工具里确认第三方脚本加载完成后再执行。
2. 后续绑定的事件：如果之后还有其他脚本会绑定scroll事件，这个方法不会处理那些新绑定的事件。如果需要覆盖后续的绑定，你可能需要重写jQuery的on方法来自动节流scroll事件，但这属于进阶操作，你的场景里先处理已有的应该就够了。

现在再去看开发者工具的Global Event Listeners，应该能看到新绑定的事件，而且滚动时的性能开销会明显降低。

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