现代 iOS Safari 9.3+ 在 viewport 正确配置 initial-scale=1.0 时默认消除 300ms 延迟，但 PWA、旧版 WebView 或配置不全时仍复现，需 HTML、CSS 协同生效。
现代 iOS Safari（9.3+）在正确配置 viewport 且含 initial-scale=1.0 时，默认消除 300ms 延迟；但 PWA 添加到主屏幕后、旧版 WebView 或未显式声明缩放控制时，延迟仍会复现——HTML 层不是万能解药，而是第一道防线，必须精准配置，否则后续所有 CSS/JS 补救都可能失效。
viewport meta 必须显式写全 initial-scale=1.0
只写 width=device-width 是常见错误，它不触发双击判定优化逻辑。iOS 9.2 及更早版本即使写了该属性也照常延迟；UC、QQ 浏览器旧版 WebView 同样依赖 initial-scale=1.0 才启用优化。
-
minimun-scale或min-scale拼错会导致整个<meta>失效，务必核对拼写 - 必须放在
<head>内静态声明，动态插入或写在<body>中解析失败 -
user-scalable=no或maximum-scale=1.0是真正关闭双击缩放判断的开关，Chrome/Safari/Firefox 移动版均据此取消延迟 - 避免混用
user-scalable=no和minimum-scale=1.0——后者无实际作用，纯属冗余
touch-action: manipulation 不能全局设在 html/body 上
设置 touch-action: manipulation 能禁用双击缩放和长按菜单，从而移除延迟，但它只对明确用于点击的元素生效。全局设在 html 或 body 上会破坏页面纵向滚动，且无法继承——父元素设了，子元素默认仍是 auto，需单独加。
- 只加在具体交互容器上，例如
<button class="js-tap-target">，再配 CSS：.js-tap-target { touch-action: manipulation; } - IE10/11 需前缀：
-ms-touch-action: manipulation; -
touch-action: manipulation !important语法错误，会被忽略；应检查 computed style 确认最终生效值 - 若元素绑了
ontouchstart或监听touchmove，某些浏览器会自动降级回 300ms 行为（防误触）
PWA 场景下 viewport 单独失效，必须补 CSS 干预
iOS Safari 在「添加到主屏幕」后的 PWA 模式下，即使 <meta name="viewport"> 完整，部分机型（尤其 iOS 15~16 旧 patch 版本）仍保留延迟。此时 HTML 层已无能为力，必须靠 CSS 提前介入。
立即学习“前端免费学习笔记（深入）”；
- HTML 中为关键按钮预留 class，如
<button class="pwa-tap"> - CSS 中明确写：
.pwa-tap { touch-action: manipulation; } - 不要指望
user-scalable=no在 PWA 中“自动生效”——它只是准入条件，不是充分条件 - 若页面需保留缩放能力（如图库、PDF 预览），
user-scalable=no不可用，只能靠touch-action精准打点
uni-app 或 scroll-view 内点击失效的隐藏条件
真机调试时点击无反应，常不是延迟问题，而是 iOS 对可点击区域有隐性要求。uni-app 的 @click 在 H5 环境本质是模拟 click，@tap 更不可靠；@touchend 虽即时，但必须配合防误触与尺寸保障。
- 元素物理尺寸必须 ≥44px × 44px（CSS 像素），
padding或min-height没设够就点不中 - 检查
z-index是否被 fixed 导航栏、蒙层遮挡，用 Safari 真机调试器选中元素看渲染层级 - 若在
<scroll-view>内且启用了enhanced属性，某些 iOS 版本会劫持 touch 事件，导致@click失效 - 用
@touchend时务必加e.preventDefault()，否则可能触发“幽灵点击”
最容易被忽略的是：组件库（如 Vant 早期版本）内部已封装 fastclick，你写的 touch-action 会被 JS 层拦截覆盖；还有 PWA 场景下 viewport 和 CSS 必须协同生效，缺一不可——单点修复大概率失败。
