Chrome内容脚本中wheel事件调用window.scrollBy后滚动被立即撤销问题

核心机制：Chrome的滚轮滚动意图优先级保护 #

Chrome为了避免脚本随意打断用户的原生滚轮操作，在滚轮事件的处理链路中设计了强制的校验逻辑，完整执行顺序如下：

• 当鼠标滚轮触发一次滚动时，Chrome会在同一个任务循环内按固定顺序执行：
  1. 向所有事件监听器（包括内容脚本、页面自带脚本）派发wheel事件
  2. 根据滚轮滚动的距离、系统阻尼参数，计算原生滚动的目标位置，将视口滚动到该位置
• 如果你在wheel事件处理器内直接调用window.scrollBy(0, window.innerHeight)，这个脚本触发的滚动会先于第2步的原生滚动逻辑执行。此时Chrome会判定：当前用户的滚轮输入还处于未完成的事件链路中，脚本强制触发的滚动与用户原生的滚轮输入意图存在竞争，因此会在原生滚动逻辑执行完成后，将视口位置回滚到原生计算的目标值——这就是观察到的「页面闪烁」现象：先渲染脚本设置的滚动位置，紧接着被强制回退。

不同场景下表现差异的解释 #

• 从浏览器控制台执行window.scrollBy可正常生效：控制台代码的执行完全脱离wheel事件的任务上下文，不会触发上述的滚动意图竞争校验。
• 延迟调用的临界值为175ms：
  • 这个临界值是Chrome内部的滚轮意图保留窗口的实际体现：一次wheel事件触发后，Chrome会将本次用户滚轮输入标记为有效意图，保留150~200ms的校验周期，只有等这个周期走完，确认本次滚轮输入对应的惯性滚动、阻尼计算全部完成，脚本触发的滚动才不会被判定为冲突操作。你实测的175ms是当前Chrome版本、硬件配置下的该窗口实际值，不同环境下会有小幅浮动。
  • 使用Promise延迟的效果与短超时setTimeout完全一致的原因：在wheel事件处理器内直接通过微任务调度执行的滚动，运行时机仍处于滚轮意图的校验窗口内，依然会被判定为冲突操作，因此和超时175ms以下的行为完全相同。

Firefox无该问题的原因 #

Firefox的滚动事件处理流水线没有内置上述的强制回滚逻辑，脚本触发的滚动和原生滚轮滚动会按照调用顺序依次应用，因此不需要额外延迟就能正常生效。

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