现代移动端无法可靠禁用用户缩放，user-scalable=no 在 iOS 10.3+ 和多数 Android Chrome 中被忽略，且违反 WCAG 2.1 可访问性标准；应改用 width=device-width、initial-scale=1.0、minimum-scale=0.5、maximum-scale=2.0 组合，并省略 user-scalable；强约束场景才用 JS 拦截多点触控并配合 touch-action: manipulation。
现代移动端已无法可靠禁用用户缩放，user-scalable=no 在 iOS 10.3+ 和多数 Android Chrome 中已被忽略或弱化；强行禁用会破坏可访问性，且违反 WCAG 2.1 标准。
为什么 user-scalable=no 不再起作用
iOS Safari 自 10.3 起无视该值，双指缩放、双击放大仍可触发；Android Chrome 也逐步降权处理。更关键的是：屏幕阅读器、视力障碍用户依赖系统级缩放（如「更大字体」）调整文字大小，user-scalable=no 会直接绕过这些辅助能力，导致文字被截断、按钮点不到——这不是“体验优化”，而是功能拒斥。
常见错误现象包括：
• 页面在 iOS 添加到主屏后缩放失效但手势仍响应
• 开启系统「显示缩放」后文字突然变小或溢出容器
• Lighthouse 审计直接报 user-scalable=no 可访问性违规
应该用哪些 viewport 参数替代
真正被广泛尊重、语义清晰且兼顾可控性的组合是：
-
width=device-width：必须存在，否则其他 scale 参数可能不生效 -
initial-scale=1.0：配合width=device-width防止首次加载缩放抖动 -
maximum-scale=2.0：允许必要放大（如查看图片细节），又防拉伸变形 -
minimum-scale=0.5：避免意外缩小导致内容不可读（可选，但建议设）
完整写法示例：<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=0.5, maximum-scale=2.0">
注意：user-scalable 字段完全省略——它不是必需项，显式写 yes 或 no 反而增加歧义和兼容风险。
真要锁死缩放？JS + CSS 才是兜底手段
仅当业务场景强约束（如 Kiosk 自助终端、WebGL 游戏画布），且 native 层已统一接管手势时，才考虑运行时拦截：
- 在
上监听touchstart，检测event.touches.length > 1后立即event.preventDefault() - 必须加
{passive: false}，否则 iOS Safari 会忽略preventDefault() - CSS 补充
touch-action: manipulation（非none），避免滚动卡顿，同时明确告知浏览器“只处理点击/轻触” - 切勿全局拦截
touchmove：这会直接废掉页面滚动，iOS 下甚至触发静默卡死
示例片段：
document.body.addEventListener('touchstart', e => {<br> if (e.touches.length > 1) e.preventDefault();<br>}, { passive: false });<br>document.body.style.touchAction = 'manipulation';
最容易被忽略的三个落地细节
写对配置只是第一步，真实设备上常因以下原因失效：
-
viewport标签没放在最前面——被 SSR 模板注释、框架占位符或其它<meta>挤到后面，Safari 直接按默认 980px 渲染首屏 - 使用相对路径或未创建的目录写
dir（虽然这是 Redis 的坑，但同理：viewport 写错位置 = 白写） - 未真机测试：Chrome DevTools 的「Device Mode」模拟缩放行为不等于真实双指操作，尤其 iOS 17+ 对
maximum-scale的处理更保守
验证是否生效，只做三件事：在 iPhone 上打开页面 → 双指张开试缩放 → 双击放大 → 开启系统「更大字体」看文字是否正常重排。任何一环失败，就说明配置或实现没落到位。
