iOS Safari自iOS 13.4起无视user-scalable=no，仅当minimum-scale=maximum-scale=1.0且initial-scale=1.0时才禁用缩放；安卓需组合使用全部属性并辅以JS拦截和真机验证。
viewport 的 user-scalable=no 为什么在 iOS Safari 上失效
iOS 13.4+ 的 Safari 默认忽略 user-scalable=no，这是 Apple 主动移除的行为限制，不是 bug。它出于可访问性考虑强制保留用户双指缩放能力，哪怕你写了 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">，实际仍可缩放。
真正起作用的只有 maximum-scale=1.0，但注意：仅当 minimum-scale 和 maximum-scale 相等且为 1.0 时，Safari 才会禁用缩放（iOS 15.4+ 更严格，需三者同时满足）。
-
initial-scale=1.0必须显式声明，否则部分 Android 浏览器可能忽略后续缩放限制 -
minimum-scale=1.0和maximum-scale=1.0缺一不可；只写其中一个无效 - 不要依赖
user-scalable=no做功能兜底，它已被 Safari 视为废弃提示
安卓 WebView 和 Chrome for Android 的兼容写法
Android 端对 viewport 属性支持更宽松，但不同 WebView 内核版本行为不一。例如 Android 9+ 的系统 WebView 默认启用 pinch-zoom，必须靠 maximum-scale=1.0 配合 user-scalable=no 才能稳定禁用。
推荐统一使用以下组合，覆盖绝大多数安卓机型和 Chrome 版本：
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no">
- Chrome 110+ 开始对
user-scalable=no加强校验，缺失minimum-scale或maximum-scale会导致该属性被静默忽略 - 某些定制 ROM（如华为 EMUI）会额外拦截
touchstart事件来阻止缩放，但不可靠，不应作为主要手段 - 若页面内有
<input>聚焦，部分安卓机型仍会临时放大（这是系统级行为，viewport 无法干预）
禁用缩放后必须处理的交互副作用
禁用缩放不等于禁用触摸交互，反而会让用户误操作更明显——比如双击误触发 zoom，或长按弹出菜单遮挡内容。这时候需要补一层 JS 防御。
- 监听
touchmove并检查event.scale !== 1，调用event.preventDefault()阻断缩放手势（仅对非原生缩放有效） - 给
添加style="-webkit-text-size-adjust: none;"，防止 iOS 自动调整字体大小引发重排 - 避免在禁用缩放页面中使用
transform: scale()动画，容易与缩放状态混淆，导致视觉错乱
真机测试时最容易漏掉的两个检查点
模拟器或桌面 Chrome 的 device mode 完全无法复现真实缩放行为，必须用真机验证。重点看这两个地方：
- 横屏旋转后是否重置了缩放状态？iOS 在 orientationchange 后可能恢复默认缩放，需监听
window.orientation或resize事件并重设document.documentElement.style.zoom = "1" - 微信内置浏览器（X5 内核）会无视
maximum-scale，必须额外注入 X5 专属 meta：<meta name="x5-orientation" content="portrait"> <meta name="x5-fullscreen" content="true">
viewport 是声明式约束，不是强制锁死。真正可靠的禁用，永远是「声明 + JS 拦截 + 真机验证」三层叠加，少一层都可能在某个机型上突然失效。
