移动端click事件300ms延迟源于浏览器为识别双击缩放而设的等待机制;禁用缩放(如viewport中设user-scalable=no)可消除延迟,但牺牲双指缩放功能;现代浏览器在width=device-width+initial-scale=1.0下部分优化延迟;FastClick需挂载document.body实现事件委托;自定义tap必须判断touchmove以区分点击与拖拽。
移动端 click 事件的 300ms 延迟不是 HTML 本身的问题,而是浏览器对双击缩放的兼容策略导致的;你不能靠改 <html> 标签或写个新 HTML 规范来解决它——得从 viewport 控制、事件绑定方式或 JS 行为干预入手。
click 还有延迟吗绝大多数情况下没有。当页面明确声明不支持用户缩放,浏览器就认为“双击缩放”无意义,会直接跳过 300ms 等待逻辑。
<meta name="viewport" content="width=device-width, user-scalable=no"> 是最轻量的开关,但代价是彻底禁用双指缩放(包括图片放大等合理场景)maximum-scale=1.0 或 user-scalable=no 即可生效,不需要同时写多个属性width=device-width + initial-scale=1.0 组合下,即使没禁用缩放,部分场景也会自动优化掉延迟(但不保证稳定)FastClick 的 attach 为什么必须作用于 document.body
FastClick 依赖事件委托:它在 document.body 上监听 touchend,再根据目标元素判断是否模拟 click 并阻止原生 click。若挂载到子容器,会漏掉非该容器内的点击。
FastClick.attach(document.getElementById('app')),否则页脚、弹层等动态插入的节点无法被接管body 的直系后代,且生命周期里正确调用 detach() 避免内存泄漏<input type="text"> 等聚焦类元素,FastClick 默认跳过模拟,但 iOS 上仍可能出现软键盘唤起不灵敏——需手动 patch focus 方法(见知识库末段代码)tap 时为什么必须判 touchmove
不判 touchmove 就等于把“按住拖动”也当成点击,UI 交互会失控。真正的点击必须满足:起点与终点位置偏移极小、持续时间短、中途无位移。
立即学习“前端免费学习笔记(深入)”;
touchstart + touchend 时间差 touchmove 中设标志位(如 isMove = true),并在 touchend 里检查该标志tap 还额外做了坐标距离判断(Math.abs(dx) ),比单纯判 move 更严谨
穿透问题最容易被忽略:哪怕你用了 FastClick 或自定义 tap,只要上层元素消失后下层是 <a>、<input> 或绑了 click 的按钮,300ms 后原生 click 仍会落到下层——这不是延迟没解决,而是你没同步阻止它。真正健壮的做法,是在隐藏遮罩层的同时,给下层元素临时加 pointer-events: none,或在 touchend 阶段就 e.preventDefault() + e.stopImmediatePropagation()。