移动端click事件300ms延迟源于浏览器为识别双击缩放而设的等待机制，禁用缩放的viewport可消除该延迟，现代浏览器通过touch-action:manipulation或语义化按钮已原生优化。
移动端 click 事件的 300ms 延迟到底从哪来
这不是 bug，是 Safari（以及早期 Chrome、Android 浏览器）为区分单击和双击缩放而引入的等待机制。用户手指抬起后，浏览器会等约 300ms，看是否还有第二次点击；只有确认不是双击，才触发 click。这在桌面端无关紧要，在触屏设备上却直接导致按钮“点了没反应”的错觉。
注意：这个延迟只存在于非 viewport 缩放禁用的页面中。只要页面有如下 meta 标签，延迟就基本消失：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
但仅靠这个还不够——iOS Safari 15+ 和 Chrome Android 80+ 已默认对 <button></button>、<a></a> 等可交互元素做优化，前提是它们满足“可点击语义”（比如有 role="button" 或原生类型），且未被 pointer-events: none 或透明遮罩层拦截。
用 touchstart 替代 click 的风险与边界
很多人一上来就改用 touchstart 绑定回调，以为能立刻响应。但这样做容易踩三个坑：
立即学习“前端免费学习笔记（深入）”；
- 误触发：手指刚碰到屏幕就触发，哪怕只是滑动准备，用户还没“决定点击”
- 无反馈：原生
click自带 :active 伪类样式，touchstart不会自动激活，需手动加 class 或 CSS 变量控制 - 兼容性断层：部分旧版 UC、QQ 浏览器对
touchstart的preventDefault()行为处理不一致，可能干扰后续滚动
更稳妥的做法是保留 click，但用 addEventListener('click', handler, { passive: false }) 显式声明可取消（尤其当 handler 内部调用 preventDefault() 时），避免浏览器因默认 passive 导致事件被静默忽略。
FastClick 库现在还值得引入吗
FastClick 曾是解决 300ms 延迟的事实标准，但现在它已过时。原因很实际：
- 现代浏览器（Chrome 56+、Firefox 53+、Safari 10.3+）已原生支持
touch-action: manipulation，一行 CSS 就能关闭延迟 - 引入 FastClick 会增加约 10KB JS，且需额外初始化逻辑，反而拖慢首屏
- 它会劫持所有
touch事件，与某些轮播图、手势库（如 Hammer.js）冲突概率高
替代方案极其简单：给按钮或其父容器加上
button, .js-clickable { touch-action: manipulation; }
该属性明确告诉浏览器：“这个区域只用于点击/轻触，不用等双击，也不用考虑缩放”。iOS Safari 和 Chrome 安卓均支持，且不影响滚动区域的正常行为。
按钮本身结构对响应性能的影响
很多人忽略一点：按钮是否能被快速识别为“可点击”，直接影响事件注册效率。以下写法会拖慢响应链：
- 用
<div onclick="..."> 模拟按钮：缺少语义，部分浏览器不会提前优化其事件路径 <li>嵌套过深：如 <code><button><span><i><em>提交</em></i></span></button>，事件冒泡路径长，且可能因子元素阻止冒泡导致失效 - 动态插入后未重绑事件：用
innerHTML插入新按钮，但忘记调用addEventListener
最优实践是：用原生 <button type="button"></button>，内联文本或单层 <span></span>，并确保它在 DOM ready 后已存在。若必须动态生成，优先用 document.createElement('button') + append()，而非字符串拼接。
真正卡顿的根源，往往不在“怎么绑事件”，而在“按钮是不是浏览器一眼认出的按钮”。别让语义妥协换来的那点样式自由，反把响应延迟又拉回 300ms。
