直接加 touch-action: manipulation 能解决大部分 300ms 点击延迟，但只对明确可点击的元素生效，且必须配合语义、viewport 和真机验证，否则白加；需显式设置在自定义按钮（如 <div class="btn">）、轮播指示点、Tab 标签、弹层关闭按钮等高频操作区，原生可点击元素默认已优化但重写 display 或覆盖 touch-action 时须手动补回，而轮播容器、地图等需手势区域禁用该属性。
直接加 touch-action: manipulation 能解决大部分 300ms 点击延迟，但只对明确可点击的元素生效，且必须配合语义、viewport 和真机验证，否则白加。
哪些元素必须显式设置 touch-action: manipulation
这个属性不继承，父级设了，子级默认还是 auto；浏览器只在触发原生 click 的上下文中检查它。
-
<button>、<a>、<input type="button">等原生可点击元素默认已优化，但如果你重写了display（比如改成inline-block）或覆盖了touch-action，就得手动补回 - 所有用
onclick、@click、onClick绑定的自定义容器（如<div class="btn">、<li class="card">）必须单独加，不能靠父级兜底 - 轮播图指示点、Tab 标签页、弹层关闭按钮这类高频操作区，优先加；但轮播图外层容器、地图区域、横向滚动列表不能加——否则会禁用滚动
- fixed 定位或带
transform的元素，在部分 Android WebView 中会忽略该声明，需额外补上
为什么加了 touch-action: manipulation 还是延迟
不是语法写错，而是被更高优先级规则或运行时行为覆盖了。
- 父容器设置了
touch-action: auto或none（比如某些 UI 框架的.modal、.drawer），会阻断子元素的manipulation行为 - CSS 选择器权重不够：第三方样式表里有
* { touch-action: auto }，你的声明直接被干掉；用 DevTools 的 Computed 面板确认最终值是不是manipulation - 元素没交互语义：纯
<div>即使加了该属性，iOS Safari 仍可能不加速，得配role="button"和tabindex="0" - 监听了
touchstart或touchmove：某些浏览器检测到 JS 手动干预后，会自动降级回 300ms 判断逻辑；若必须监听，记得传{ passive: true }
如何验证是否真正生效
别信模拟器，真机测最准；延迟消失后，视觉反馈也得跟上。
立即学习“前端免费学习笔记（深入）”；
- 在 Safari 或 Chrome 真机调试中打开 Elements 面板，选中按钮，看 Computed 样式里
touch-action是否为manipulation - 长按按钮约 200ms 后松开，如果
click立即执行（比如弹窗秒出、路由瞬跳），说明生效；如果仍有明显“停顿感”，大概率是 JS 层拦截了事件流 - 禁用 300ms 延迟后，
:active伪类会立刻触发，但部分设备（如带物理键盘的 iPad）仍会进入焦点状态，所以至少要同时定义:active和:focus；避免只依赖:hover，它在多数触摸设备上不触发 - 用
console.time()和console.timeEnd()在click回调里打时间戳，看实际触发间隔是否稳定在 10ms 内
最容易被忽略的是：有些组件库（比如早期 Vant、Mint UI）内部封装了 FastClick，即使你写了 touch-action，JS 层仍会接管事件流。这时候得关掉库的 FastClick 选项，或者手动 patch 初始化逻辑；另外，display: none 隐藏遮罩层后 click 仍按原坐标下发，这不是 touch-action 能解决的问题，得换用 visibility: hidden + pointer-events: none。
