touch-action: none 不会彻底禁用双指缩放，它禁用所有原生触摸行为，但受层叠规则影响，祖先元素的 auto 值可能覆盖它；需配合 viewport 中 user-scalable=no 才能可靠禁用双击缩放。
touch-action: none 会彻底禁用双指缩放吗
不会。设置 touch-action: none 会禁用所有原生触摸行为，包括双指缩放、平移、滚动，但前提是该元素及其祖先没有更宽松的 touch-action 值覆盖它。浏览器按层叠规则取最近的非 auto 值生效。常见误判是只给子容器设 none，却忘了父级 div 默认是 auto，结果实际行为仍由父级决定。
实操建议：
- 用 Chrome DevTools 的「Rendering」面板勾选 “Highlight touch actions”，可实时看到哪些区域响应了什么触摸行为
- 若只要禁用缩放、保留滚动，应改用
touch-action: pan-y pinch-zoom（iOS Safari 支持，Android Chrome ≥ 61） -
touch-action: manipulation是更安全的折中方案：禁用双击缩放和长按菜单，保留滚动与单指拖拽，兼容性更好（iOS 9.2+ / Android 5.0+）
为什么加了 touch-action 还是触发了双击缩放
最常见原因是页面 <meta name="viewport"> 配置不完整。即使 CSS 层面限制了 touch-action，浏览器在检测到缺失 user-scalable=no 或 maximum-scale=1.0 时，仍可能对双击事件执行默认缩放逻辑。
检查并修正 viewport 声明：
- 必须包含
user-scalable=no，仅靠maximum-scale=1.0不足以阻止 iOS Safari 的双击缩放 - 避免写成
initial-scale=1, maximum-scale=1却漏掉user-scalable—— 这在 iOS 上形同虚设 - 如果业务允许用户缩放（如图文阅读页），就不要强行用
touch-action: none，而应监听gesturestart事件并event.preventDefault()
touch-action 对自定义手势库（如 Hammer.js）的影响
设为 none 或 manipulation 后，touchstart/touchmove 事件仍会触发，但部分浏览器（尤其是旧版 Android WebView）可能延迟或截断事件流，导致 Hammer.js 的 pan、pinch 识别失败。
关键适配点：
- 优先使用
touch-action: manipulation而非none，它保留基本手势事件通道 - 初始化 Hammer.Manager 时显式传入
{touchAction: 'none'}，否则其内部默认行为可能与 CSS 冲突 - 在 iOS 上，若同时监听
touchmove并调用preventDefault()，必须确保在passive: false模式下绑定事件（否则会被浏览器忽略）
移动端真机测试时 touch-action 失效的典型原因
开发时在桌面 Chrome 模拟器里看着正常，一上真机就失效，大概率是渲染层未触发重绘或样式未生效。iOS Safari 尤其敏感：它要求 touch-action 必须作用于有明确尺寸（width/height 或 min-height）且非 display: none 的元素；若元素靠 flex 或 grid 自适应撑开，某些版本会忽略该声明。
保底验证步骤：
- 给目标元素加
outline: 1px solid red，确认它在真机上有渲染盒（而非塌陷） - 避免用
transform: translateZ(0)强制硬件加速——这在部分 Android 机型上会绕过touch-action控制 - 检查是否被 WebKit 内核的「快速点击延迟」干扰：未设置
cursor: pointer或缺少onclick属性的元素，在 iOS 上可能跳过触摸行为解析
复杂点在于，touch-action 的生效依赖渲染树、事件流、内核策略三者协同，任一环节脱节都会静默失效——它不像 display 那样直观可见。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
