触屏上的点击延迟可能让两次快速点击都被判定为有效
别名: 幽灵点击 · 双击都有效 · ghost click
概念解释
触屏上一次按下会走出一串事件：touchstart、touchend，过一小段兼容延迟再来一次 click。用户若因为没看到立刻反馈而再点，第二次触摸和第一次延迟到达的 click 都可能被当成有效提交。点击延迟让两次快速点击都有效，不是用户点了两次意图，是同一意图被事件模型复制，或两下都落在锁生效之前。
机制
为了判断是滚动、双击缩放还是单击，部分 WebView 仍会把合成 click 推迟约 300 ms。应用若在 touchend 里已经发请求，又在 click 里发一次，一记轻点变成两发。即便只监听 click，人在这 300 ms 里再点，两记 click 排队，锁若在异步里才立，两记都通过。300 ms 也正好是「没反应再点」的时间窗。原生应用没有这套兼容 click，但触摸采样和 UI 线程卡顿同样能让两记 pointerup 在锁之前到达。防重复如果只做「忽略 500 ms 内的第二次 click」却把第一次 touchend 和它派生的 click 当成两次不同入口，延迟复制仍能穿过。
怎么研究
在带 300 ms 合成 click 的 WebView 和没有该延迟的原生控件上，对提交键做一记轻点和一记连点。记录事件序列与请求数。
自变量：监听 touchend 还是 click 还是两者、锁是同步还是等下一帧、是否禁用 300 ms 延迟（viewport 或 CSS touch-action）。 因变量：单次轻点的请求数、连点的请求数、事件日志里 click 是否晚于第二次触摸。
用桌面鼠标点触屏模拟器会看不到合成延迟。要用真机或能复现 300 ms 的 WebView。
边界
需要双击的控件（地图缩放、文本选词）不能把第二次触摸一律当重复提交。游戏连发按键要的就是两次都有效。300 ms 延迟在现代浏览器里已少很多，但内嵌 WebView 和旧 Android 仍在。锁若足够同步，延迟复制也过不来，所以根治在锁，不在猜测延迟数字。
怎么落地
- 只在一条事件上发出请求（优先 click 或 pointerup 之一），不要 touchend 与 click 各发一次。
- 锁放在事件处理的同步开头，不要等动画帧。
- 对非缩放的提交按钮设置合适的触摸行为，避免浏览器为双击缩放而推迟 click。
- 验证：真机上对付款键一记轻点、再一记间隔约 200 ms 的连点。轻点不得出现两条请求；连点在锁有效时应仍是一条。