移动端惯性滚动下 Click 事件失效：底层原理深度解析移动端惯性滚动时Click事件失效，根源是浏览器**制动优先**

移动端惯性滚动下 Click 事件失效：底层原理深度解析

在移动端（iOS/Android）开发中，当一个容器处于 惯性滚动（Momentum Scrolling） 状态时，用户点击页面上的按钮（即使是 absolute 定位元素），往往需要点击两下才能触发。这种现象并非 Bug，而是浏览器渲染引擎与交互设计规范共同作用的结果。

以下从浏览器架构、事件合成链、线程协作三个维度进行深度分析。

移动端浏览器的交互设计遵循一个核心原则：“制动优先（Brake First）”。

交互意图判定：当用户在页面快速滚动时按下手指，浏览器的第一优先级不是“寻找落点下的元素”，而是**“停止当前的物理运动”**。
事件消耗（Event Consumption）：在惯性滚动未停止时，触摸动作会被滚动控制器（Scroll Controller）直接拦截。浏览器会将这一次触摸序列判定为“减速/停止”指令。为了防止用户在想停止滚动时误触跳转链接或提交按钮，系统会消耗掉该次触摸序列，使其无法向上传递合成为 click 事件。

现代浏览器（WebKit/Chromium）采用多线程架构，这是导致 click 响应滞后的技术根源。

滚动中：合成器线程完全接管页面，此时页面处于“高速运动图层”模式。
点击发生：
- 当手指触碰屏幕，合成器线程首先感知。
- 它发现当前正在执行惯性滚动，于是立即停止动画（Scroll Stop）。
- 关键点：由于合成器线程追求极速响应，它在停止动画的一瞬间，并不会同步去咨询主线程：“这一像素下有没有绑定 Click 事件？”
- 为了性能，它通常直接拦截掉这一帧的输入流，导致主线程收不到完整的事件信号。

这是理解问题的关键。click 和 touchstart 在浏览器底层的处理逻辑完全不同。

click 事件的触发依赖于一个完整的、连续的事件链条：

touchstart → touchmove (位移需极小) → touchend → [验证逻辑] → click

断裂过程：在惯性滚动中，当浏览器判定该触摸用于“停止滚动”时，它会截断这个链条。虽然 touchstart 发生了，但随后的状态被系统置为“已处理默认行为（停止滚动）”，导致后续的 touchend 不再派生出 click 事件。

touchstart 是物理触摸的第一信号，它的触发时机极早：

你提到的 absolute 布局按钮虽然在视觉上固定，但它在浏览器的 层叠上下文（Stacking Context） 中依然属于滚动容器所在的渲染树或合成层。

全局手势识别：移动端的手势识别（Gesture Recognizer）是作用于整个視口（Viewport）或滚动上下文的。
只要你的手指落点在滚动容器的坐标范围内，浏览器就会优先启用滚动控制逻辑。除非该元素完全脱离滚动容器的 DOM 层级（即：作为滚动容器的兄弟节点而非子节点），否则它都会被卷入滚动的状态管理中。