现代iOS Safari（9.3+）在正确配置viewport且含initial-scale=1.0时默认消除300ms延迟；PWA添加到主屏幕后仍需touch-action: manipulation补救，viewport仅为准入条件而非充分条件。
现代 iOS Safari（9.3+）在正确配置 <meta name="viewport"> 的前提下，300ms 延迟已默认消除；真正需要 HTML 层面干预的，是 iOS 9.2 及更早版本、PWA「添加到主屏幕」后未触发优化、或 WebView 内核陈旧的场景。
viewport 必须显式声明 initial-scale=1.0
仅写 width=device-width 是常见错误——它不触发多数浏览器的双击判定优化逻辑。iOS 9.2 及更早版本甚至在写了该属性后仍会等待 300ms。
-
initial-scale=1.0必须显式写出，缺省时 UC、QQ 浏览器旧版等安卓 WebView 不会启用优化 - 避免拼写错误：
minimun-scale或min-scale会导致整个<meta>失效 - 必须放在
<head>内静态声明；动态插入或写在<body>里，解析失败，延迟照常
user-scalable=no 不是万能开关，但最可靠
加了 user-scalable=no 或 maximum-scale=1.0 才是真正关闭双击缩放判断的开关，Chrome / Safari / Firefox 移动版均会据此取消 300ms 延迟。
- 副作用明确：永久禁用所有缩放，包括用户双指放大查看图片的需求
- 若页面需保留缩放能力（如图库、PDF 预览），此方案不可用
- 不要混用
user-scalable=no和minimum-scale=1.0—— 后者无实际作用，纯属冗余
PWA 场景下 viewport 单独失效，必须补 touch-action
iOS Safari 在「添加到主屏幕」后的 PWA 模式下，即使 <meta> 完整，部分机型仍保留延迟。此时仅靠 HTML 层无法解决，必须配合 CSS 级干预。
立即学习“前端免费学习笔记（深入）”；
- HTML 本身无法补救，但可提前为关键按钮预留 class，例如：
<button class="js-tap-target"> - 后续只需加一行 CSS：
.js-tap-target { touch-action: manipulation; } - IE10/11 需前缀：
-ms-touch-action: manipulation; - 切勿全局设
html { touch-action: none; }—— 会禁用页面纵向滚动
真正容易被忽略的是：viewport 配置只是“准入条件”，不是“充分条件”。它让浏览器具备取消延迟的能力，但不保证一定执行；尤其在 PWA、WebView 或自定义交互覆盖了原生行为时，必须用 touch-action 显式声明意图。HTML 层能做的只有铺路，不能替 CSS 和 JS 做决定。
